[Vm-dev] #becomeUncompact not longer works in Cog/Stack VMs

[Eliot Miranda]

On Mon, May 9, 2011 at 1:52 AM, stephane ducasse <stephane.ducasse at gmail.com
> wrote:

>
> Hi andreas
>
> > I don't recall if Eliot has published all the details (we went over it
> during some lunch break once) but the basic idea is described here:
> >
> >
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-August/131167.html
> >
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-September/131206.html
>
>
> I read the second link multiple times but I could not get 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."
>
> I could not understand the last sentence from the second link.
>

This is a mistake on my part.  In this scheme it is impossible to have an
instance of a class and that class not have an identityHash.  I was talking
about/getting confused with the standard VisualWorks VM where a class may be
assigned an identityHash on send.  In the class index scheme classes get
assigned identity hashes either in a special version if the identityHash
primitive for Behavior (e.g. when one puts a class in an IdentitySet) or
when a class is instantiated.  So the check for classes having
identityHashes (which are also their table indices and hence the class
indices of their instances) is on instantiation, not send.  Sorry.


"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."
>
> I could not understand the trick of entering the weakarray twice.
>

So we want to use WeakArray for the class table pages since we don't want to
hold onto classes strongly through the class table, only through instances.
Bt the class table should remain a hidden object, not visible to the image;
it is part of the VM implementation, not an official part of the
specialObjectsArray.  So e.g. these pages shouldn't turn up in WeakArray
allInstances.  By using a pun for WeakArray (so that there are two entries
in the class table that map to the WeakArray class) and using one of these
only for the class table pages then WeakArray allInstances won't include
them.  I'm not sure this is so important, but it is a way of using the heap
for the VM to allocate memory without that memory becomming visible to the
image.

is this understandable yet?

best,
Eliot

>
>
>
> Stef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110509/d419c888/attachment-0001.htm