[SqF]Report of VI4 Project for Apr '02

Rob Withers rwithers12 at attbi.com
Tue Apr 9 14:48:11 UTC 2002


Martin McClure <martin at hand2mouse.com> wrote:
> At 2:32 PM -0500 4/6/02, Rob Withers wrote:

> >Of the 5 compact class bits (12-16 of the base header, I believe) let us
> >use bit 16 as a special oop flag.   Then I propose the following uses
> >for the other four:
> >
> >16	15	14	13	12
> >0	x	x	x	x		normal oop maybe compact class
> >1	0	0	0	0		GC forwarder
> >1	0	0	0	1		read-only oop
> >1	0	0	1	0		custom lookup/structure
> >1	0	0	1	1		signal
> >1	0	1	0	0		foreign ref
> >1	0	1	0	1		promise
> >1	0	1	1	0		broken reference
> >1	0	1	1	1		unassigned
> >1	1	x	x	x		three extra hash bits (12-14)
> >

> Parts of this proposal could probably work, but I see some drawbacks.
> 
> The 'read-only' feature is really a 'let me know if someone tries to 
> write to this object' feature. To be useful for proxy and persistence 
> schemes (the primary use I had in mind), it needs to be able to be 
> turned on and off during the life of an object. It also really needs 
> to be applicable to *any* object. Under this proposal, if I want to 
> make an object of a compact class read-only, I have to make its 
> header longer, which involves copying the object to somewhere else in 
> memory, and updating pointers to it. A bit more of a complexity and 
> performance hit than I'm comfortable with, as changing an object's 
> read-only bit can happen fairly often in a proxy or persistence 
> scheme.
> 
> If the object has extra hash bits, it's worse. I *can't* change it to 
> be read-only without corrupting all hashed collections that are 
> relying on those hash bits. Coming up with a hashing scheme that 
> makes good use of bits that only *some* objects have would add 
> considerable complexity as well, though it probably could be done.

I really love learning about the VM and object representation.  It's
such a wonderful puzzle.  I read your reply and said to myself, of
course you would want the read-only flag to be applicable to all
non-immediate representations.  The above doesn't really work.

Furthermore, I was confused between the hash bits and the size; it is
the size that could be expressed in an extended fashion with the 3rd
header word.  We really only want to hash from a consistent space.

I went to look at the entire base header layout, to see if there were
any other possible free bits, and ran into another puzzle.  If bit 0 is
the integer flag, then which bits are the 2 header type bits? 
ObjectMemory/TypeMask reads like it is bit 0 and 1 but that looks like
it collides with the integer bit.  So I suspect that the layout is as
follows:

0		integer flag
1-2		header type
3-8		size
9-12		object format
13-17	ccIndex
18-29	hash
30		root GC bit
31		mark GC bit

Is this the correct layout?  The docs mention three GC bits (mark, old,
dirty) and I don't see them.  I also don't see where a right shift 1
occurs to make the header type the low two bits.  Is #longAt: shifting? 
No way!

Regardless, it would be nice to get two bits out of this, one for the
read-only flag and another for custom lookup.  Since custom lookup just
seems to be a different header type, perhaps we could add a bit to the
header type.

cheers,
Rob



More information about the Squeak-dev mailing list