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