[squeak-dev] Using class indexes instead of reference in oop header (in COG)

Eliot Miranda eliot.miranda at gmail.com
Mon Sep 1 20:25:39 UTC 2008


On Sun, Aug 31, 2008 at 7:37 AM, Igor Stasenko <siguctua at gmail.com> wrote:

> Hi all,
>
> I wanted to ask Eliot about some details how he planning to use new
> object format in Cog.
> I think it may be interesting to others, so i posted it here.
>
> At ESUG, Eliot mentioned that new object format will be 64 bit
> (regadless of platform), and he will use a class indexes (pointing to
> entry in a global classes table) in header instead of direct class
> oop.
> Currently, in Squeak VM same principle is used for so-called compact
> classes, where in oop header is stored an index of compact classes
> array entry, which allowing to have a smallest possible oop header (32
> bits).
>
> So, in Cog, to determine an oop class, first it reads an index from
> its header, and then reads a class oop from classes global table.
> But you need a reverse operation as well - translating class oop into
> index.
> Every time you doing #basicNew , or #primitiveChangeClass , you need
> to determine a class index by its oop value.
>
> So, the question is how this will be done?


In VisualWorks the identity hash of an object is determined lazily when
doing one of the following:

- sending a message to an object.  The object's class and the message's
selector are quertied for their identity hash.  If either object does not
have one it is assigned.  So the class object is identified from context; it
is the class of the receiver.

- sending identityHash to a class.  In VisualWorks classes have a different
version of the identityHash primitive .

In either case the class is assigned a hash that is the next unused slot in
the class table, and entered into the table at that index.

In Squeak we assign hashes when objects are instantiated.  So we would need
a special version of the new primitive to create instances of classes.  So
Metaclass would have to do something like implement new and basicNew with a
primitive that assigned the identity hash and enter it into the class table,
or override new and basicNew with a primitive that assigns the hash and
enters it into the table after instantiation.


Also, some classes may die, and obviously VM needs to do a compaction
> of global classes table at some point, to prevent maintaining a big
> table where only few of entries is used.
> Suppose i created 1000+1 classes  => each class gets own index in table.
> Then first 1000 classes is gone (when user uninstalling something).
> Now you having 1000 free entries in table. But last one is still in
> use, and if you want to make table more compact it would require to
> visit each instance of that class and set a new index value.



With either the VW lazy or Squeak eager approach the class table is weak (a
strong Array of WeakArray pages) and so the indexes/hashes of garbage
collected classes can be reused.  In the VW VM I maintained an index to the
first unused slot.  Whenever a class is reclaimed its page in the class
table is finalized.  The VM notices this and sets the index to the unused
slot to the minimum of the newly reclaimed slot and its current value.  This
way the class table stays compact and doesn't grow unnecessarily large.

One nice thing I didn't mention is that one can use "class index puns".
 There is nothing to prevent the VM from entering a class into the class
table more than once.  So I entered in WeakArray twice into the class table,
and used one as a hidden class index for the pages of the class table
itself.  When one does WeakArray allInstances, therefore, the class table
pages are not found.  Further, the finalization machinery can easily
identify a class table page, because it has a unique class index, and so the
maintennance of the first unused class table slot index is very cheap.

--
> Best regards,
> Igor Stasenko AKA sig.
>


Cheers!

Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080901/e0288822/attachment.htm


More information about the Squeak-dev mailing list