[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
|