Image format proposals... Re: [SqF]Report of VI4 Project for Feb '02

David Simmons David.Simmons at smallscript.com
Sun Feb 3 03:01:20 UTC 2002


> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org [mailto:squeak-dev-
> admin at lists.squeakfoundation.org] On Behalf Of Martin McClure
> Sent: Friday, February 01, 2002 5:05 PM
> To: squeak-dev at lists.squeakfoundation.org; Tim Rowledge
> Subject: Image format proposals... Re: [SqF]Report of VI4 Project for
Feb
> '02
> 
> At 3:15 PM -0800 2/1/02, Tim Rowledge wrote:
> >This is the initial report for the VI4 Project group.
> >
> >Goal: This project is intended to gather together all the vm and vi
> >related changes that have been proposed and which require a different
> >image format.
> >
> 
> [...]
> 
> >
> >Plans: Any further proposals for image format affecting changes are
> >needed as soon as possible; this is not something we want to do more
> >than once.
> 
> 
> I do have an image format enhancement I've been considering... and it
> seems now is the time.
> 
> Here's a very brief proposal. I can fill in details later, but I want
> let you know right away the basic idea.
> 
> I'd like to have a bit in the object header for the purpose of
> marking an object immutable.
> 
> Impact:
> I haven't seen the other proposals that affect the header, so I can't
> yet say what if anything I'm proposing to move out of the header to
> make room.
> 
> Semantics:
> New objects are created with the immutability bit cleared. There are
> primitives for setting and clearing the bit. If the bit is set and an
> attempt is made to alter any of the instance variables of the object,
> the VM takes some special action instead (most likely, an exception
> is raised). There are higher-level facilities that invoke the setting
> and clearing primitives, and for dealing with exceptions.
> 
> Usefulness:
> There are two basic classes of uses for this capability.
> 1) Preventing the modification of an object
> 2) Detecting the modification of an object

I think this is a great idea. The AOS Platform VM's have all provided
this in their object model and it has been invaluable over the years.

You might want to consider the following (getter/setter) forms:

	a) basicIsImmutable
	b) basicIsResizeable
	c) basicIsLiteral

Internally in the AOS VM these are managed by three separate bit-flags.

	a) m_isImmutable
	b) m_isResizeable
	c) m_hasVMFinalizer && m_isImmutable

There are MOP methods that ignore these flags. Standard methods honor
these properties and generate an exception when a given constraint is
violated.

When an object is constructed, the flags are set en-masse from the
classes instance-prototype flags field (a subrange of the behavior's
md_flags). This makes the constructor (instantiation) process very
efficient.

Other flags have proven to be very useful in the AOS platform VM's, but
they would be a separate discussion. 

I do not know how much of this is applicable to squeak, the AOS Platform
supports dynamically morphable headers for objects. The AOS VM
architecture is written in c++ and provides a pluggable framework for
modularly defining new object header formats. At runtime, this means
that a given object may change its header format at anytime to support
an extensible set of features efficiently. I.e., At any given time
within a running system there are objects with different header forms.

> 
> Some objects just shouldn't be modified -- Symbols, method literals,
etc.
> 
> Others you can modify, but you want to know when it happens. This is
> really useful in implementing object synchronization when the same
> logical object has a physical representation in more than one space.

> It's good for distributed object systems, object persistence systems
> (my particular interest), object-relational persistence frameworks,
> and the like.

Based on my experience with providing this in AOS Platform VM's, you
will want some additional basic property flags for distributed behavior
facilities.
	
	m_delegateSlotReads
	m_delegateSlotWrites

In addition, you will want to lay out the bit-flag fields carefully so
that you can efficiently test them en-masse. Similarly, you want them
layed out to enable efficient endian-neutralized operations for
getter/setter methods to retrieve various groups of header flags. This
is very important for packaging and module building.

You will probably also want to introduce a new kind of behavior called
<ManagedBehavior> so that you can really efficiently detect and deal
with arbitrary message delegation with no performance penalties by
leveraging instance-specific behavior facilities using ManagedBehaviors.
In effect, this uses the objects behavior as a flag in and of itself.

-- Dave S. [www.smallscript.org]

> 
> Alternatives:
> The alternatives for detecting object modifications are really
> awkward; this is a much easier way to do it.
> 
> Well, that's the barebones version. Let me know what you think...
> (not that this group is usually afraid to speak up :-)
> 
> -Martin





More information about the Squeak-dev mailing list