<br><br><div class="gmail_quote">On Mon, May 9, 2011 at 1:52 AM, stephane ducasse <span dir="ltr"><<a href="mailto:stephane.ducasse@gmail.com">stephane.ducasse@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Hi andreas<br>
<div class="im"><br>
> 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:<br>
><br>
> <a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-August/131167.html" target="_blank">http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-August/131167.html</a><br>
> <a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-September/131206.html" target="_blank">http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-September/131206.html</a><br>
<br>
<br>
</div>I read the second link multiple times but I could not get the following:<br>
<br>
"- sending a message to an object. The object's class and the message's<br>
selector are quertied for their identity hash. If either object does not<br>
have one it is assigned. So the class object is identified from context; it<br>
is the class of the receiver."<br>
<br>
I could not understand the last sentence from the second link.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">"One nice thing I didn't mention is that one can use "class index puns".<br>
There is nothing to prevent the VM from entering a class into the class<br>
table more than once. So I entered in WeakArray twice into the class table,<br>
and used one as a hidden class index for the pages of the class table<br>
itself. When one does WeakArray allInstances, therefore, the class table<br>
pages are not found. Further, the finalization machinery can easily<br>
identify a class table page, because it has a unique class index, and so the<br>
maintennance of the first unused class table slot index is very cheap."<br>
<br>
I could not understand the trick of entering the weakarray twice.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>is this understandable yet?</div><div><br></div><div>best,</div><div>Eliot</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
<br>
Stef</blockquote></div><br>