<div dir="ltr"><br><br><div class="gmail_quote">On Sun, Aug 31, 2008 at 7:37 AM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi all,<br>
<br>
I wanted to ask Eliot about some details how he planning to use new<br>
object format in Cog.<br>
I think it may be interesting to others, so i posted it here.<br>
<br>
At ESUG, Eliot mentioned that new object format will be 64 bit<br>
(regadless of platform), and he will use a class indexes (pointing to<br>
entry in a global classes table) in header instead of direct class<br>
oop.<br>
Currently, in Squeak VM same principle is used for so-called compact<br>
classes, where in oop header is stored an index of compact classes<br>
array entry, which allowing to have a smallest possible oop header (32<br>
bits).<br>
<br>
So, in Cog, to determine an oop class, first it reads an index from<br>
its header, and then reads a class oop from classes global table.<br>
But you need a reverse operation as well - translating class oop into index.<br>
Every time you doing #basicNew , or #primitiveChangeClass , you need<br>
to determine a class index by its oop value.<br>
<br>
So, the question is how this will be done?</blockquote><div><br></div><div>In VisualWorks the identity hash of an object is determined lazily when doing one of the following:</div><div><br></div><div>- 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.</div>
<div><br></div><div>- sending identityHash to a class. In VisualWorks classes have a different version of the identityHash primitive .</div><div><br></div><div>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.</div>
<div><br></div><div>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.</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;">Also, some classes may die, and obviously VM needs to do a compaction<br>
of global classes table at some point, to prevent maintaining a big<br>
table where only few of entries is used.<br>
Suppose i created 1000+1 classes => each class gets own index in table.<br>
Then first 1000 classes is gone (when user uninstalling something).<br>
Now you having 1000 free entries in table. But last one is still in<br>
use, and if you want to make table more compact it would require to<br>
visit each instance of that class and set a new index value.</blockquote><div><br></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888">--<br>
Best regards,<br>
Igor Stasenko AKA sig.<span class="Apple-style-span" style="color: rgb(0, 0, 0);"><br></span></font></blockquote></div><br><div><br></div><div>Cheers!</div><div><br></div><div>Eliot</div></div>