Object header bits wanted --- non-VM-hacking Squeakers can probab ly ignore this one

Peter Crowther pjc at datatec.co.uk
Thu Feb 4 13:39:17 UTC 1999

While looking into the concept of owned objects, I've been trying to work
out where on earth to store an owner and access control list safely.  Turns
out that the only possibility is in the object header, as I want this
capability to be available on all objects.  However, I don't want all
objects to be owned.  The new scheme should be compatible with existing
images, and existing objects should come in un-owned.

In order to fulfil this little lot, I need to steal a bit out of the first
longword of the object header to indicate an owned object.  I can then use
that bit to show an increased header size, which will hold (roughly) a
14-bit index of an owner, a 14-bit index of an ACL, a 'world execute' bit
for a CompiledMethod, and a few spare bits for expansion [do I need the type
in the bottom two bits of this word as well?].  Problem is, the existing
bits are all in use.  Surprise.

Moderately-available bits seem to be:

1. The top bit of the compact class index, which would remove the ability to
user-define compact classes but is currently 0 in vanilla images;

2. A hash bit, which would marginally(?) increase collisions in method
lookups, decrease the resolution of asOop, and cannot be guaranteed to be 0
in vanilla images.

To the VM hackers out there:

- Are there any other possibilities?

- Is anybody adding user-defined compact classes?

- Is this whole scheme about to be blown apart by other VM changes?

- Am I talking through my hat?

- What are my chances of ever getting a change like this to work
transparently with existing images?

All ideas welcome!

		- Peter

More information about the Squeak-dev mailing list