[SqF]Report of VI4 Project for Apr '02

Martin McClure martin at hand2mouse.com
Tue Apr 9 05:25:06 UTC 2002


At 2:32 PM -0500 4/6/02, Rob Withers wrote:
>Tim,
>
>I would like to make a brief comment about the Oops tag-bits.  Several
>people discussed the fact that only 16 of the 32 compact classes are
>assigned.  Since this means we have an unused bit, my suggestion would
>be to use this bit as a special Oop flag.  When this flag is set, then
>the other four compact class bits could be used for either 5 (each as a
>flag) up to 16 different states.  These different states could include
>read-only, custom lookup algorithm with special header including a
>fn-ptr to the lookup method, promise with pointer to the msg queue, far
>reference with uuid, stub for swapped out objects, etc.   We could also
>include extra hash-bits.   Here is my proposal:
>
>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)
>
>I realize that every message send will have to check this.  Would this
>hurt performance badly?  We could do:
>
>isSpecialOop: oop
>	(self isIntegerObject: oop) ifTrue: [^false].
>	^ (((self baseHeader: oop) >> 15) bitAnd: 16r2).
>
>isSpecialHash: oop
>	| flags |
>	(self isIntegerObject: oop) ifTrue: [^false].
>	flags := (self baseHeader: oop) >> 15.
>	^ ((flags bitAnd: 16r2) and: [flags bitAnd: 16r1])
>

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.

-Martin



More information about the Squeak-dev mailing list