<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 20 October 2013 15:59, Igor Stasenko <span dir="ltr">&lt;<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On 20 October 2013 15:42, Igor Stasenko <span dir="ltr">&lt;<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 22 September 2013 20:29, Eliot Miranda <span dir="ltr">&lt;<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr">Hi Levente,<br><div class="gmail_extra"><br><br><div class="gmail_quote"><div>On Sat, Sep 21, 2013 at 11:39 AM, Levente Uzonyi <span dir="ltr">&lt;<a href="mailto:leves@elte.hu" target="_blank">leves@elte.hu</a>&gt;</span> wrote:<br>



<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Great progress. I&#39;ve got a few questions about Spur and the bootstrap:<br>
- How will HashedCollections other than MethodDictionaries get rehashed? How #hash be calculated from #identityHash?<br></blockquote><div><br></div></div><div>The bootstrap first builds an image in the new format and then finds all classes in it that implement rehash and then uses the simulator to send rehash to all objects to use their own rehash method to rehash them, instead of assuming their format.  In fact, the bootstrap does not rehash all objects that understand rehash since Symbol is one of them, and its Symbol table is rehashed anyway.</div>



<div><br></div><div>hash is computed from identityHash without change, but scaledIdentityHash is changed to avoid creating LargeIntegers (the larger identityHash needs less shift also):</div><div><div>ProtoObjectPROTOTYPEscaledIdentityHash</div>



<div><span style="white-space:pre-wrap">        </span>&quot;For identityHash values returned by primitive 75, answer</div><div><span style="white-space:pre-wrap">        </span> such values times 2^8.  Otherwise, match the existing</div>



<div><span style="white-space:pre-wrap">        </span> identityHash implementation&quot;</div><div><br></div><div><span style="white-space:pre-wrap">        </span>^self identityHash * 256 &quot;bitShift: 8&quot;</div></div><div>
<div>
<br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- What will happen to primitive 138 and 139? Will we still be able to iterate over the objects in the order of their creation time?<br></blockquote><div><br></div></div><div>That&#39;s much more difficult.  I&#39;ll add allInstances and allObjects primitives which can answer the objects instantianeously without needing to enumerate.  One issue is that the scavenger could fire at any time during the enumeration and could tenure objects to old space so its in general not possible to reliably enumerate via firstInstance/nextInstance firstObject/nextObject.</div>



<div><br></div></div></div></div></blockquote><div><br>indeed.<br></div><div>i think we could breathe more freely if VM wouldn&#39;t be obliged to expose heap enumeration/walking primitives.. I just wonder, if it is possible to provide alternatives for most cases:<br>


</div><div> - finding all instances<br></div><div> - finding all pointers to subject<br></div><div>so the heap walking primitives can R.I.P.<br></div><div>.. but there could be more, which we may need and which would require heap walking.<br>


what you think?<br><br></div></div></div></div></blockquote></div><div>more for this matter: i think for all kinds of queries , like &quot;gimme all object meeting certain criteria&quot;,<br>there could be other way.<br>
</div>
<div><br></div><div>Basically, we need 1 primitive:<br></div><div>primitive takes 2 arguments: an object, and array<br>the first argument defines the root object which VM should traverse and answer the (possibly) huge<br>

</div><div>array of all objects it can reach starting from it.<br>the second argument is simply a list of objects which VM should ignore while traversing the graph<br></div><div>this gives the opportunity for user to define a filter which can be used during scanning,<br>

instead of filtering afterwards.<br><br></div><div>(as variant, there could be a 3rd argument - an array which will contain the answer,<br></div><div>like that if array not big enough to fit all found references, primitive fails, otherwise primitive answers<br>

the number of filled indices in that array. this gives opportunity for user to control the<br>size of array and preallocate it before scanning.)<br></div><div><br>I think, with such primitive, we will no longer need heap walking primitives.<br>

</div><div><div class="h5"><div> </div></div></div></div></div></div></blockquote><div><br></div><div>please, note that this primitive does not walks heap linearly but scans the graph.<br></div><div>also note, that such primitive can be really useful for serialization (to find all objects one<br>
</div><div>needs to serialize for a certain subgraph) , and improve speed of this particular task considerably.<br></div><div>also note, that with such primitive you no longer need to worry about &quot;objects moving/new objects created  while walking the heap&quot;, which certainly a weak point of current design.<br>
</div><div>And as a bonus, one don&#39;t needs to be concerned with the order of objects on heap anymore. :)<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>
Being able to enumerate in order of creation time is something the VM could maintain in old space, keeping objects in order there-in.  But I&#39;d rather drop this property and allow the Spur GC to compact using best-fit and lazy become, which will change the order of objects.  How important is being able to enumerate in order of creation?  I think it&#39;s nice to have but hardly essential.  What do y&#39;all think?</div>



<div> </div></div></div></div></blockquote><div>IMO, i would never make any assumptions, in which order objects are located on heap nor in which order <br>they get enumerated. &quot;Heap&quot; word says for itself here. (and anyone who thinks otherwise should be<br>


shot on sight :)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

- IIUC the memory is more segmented. Will there be new GC primitives for various levels of garbage collection? What about the GC parameters?<br></blockquote><div><br></div></div><div>That remains to be seen.  I take requests.  I take design suggestions.  But I also like to keep things simple.</div>



<div><br></div><div>My current approach is to keep things as compatible as possible to ease adoption.  Once it is adopted we can start to evolve to provide appropriate and.or improved management facilities.</div><div>
<div> </div>

<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- Are #become: and #becomeForward: optimized for the case where both objects use the same amount of memory?</blockquote><div><br></div></div><div>Yes.  This case simply swaps contents and adjusts the remembered table accordingly.  Tim also suggested optimizing the other case, copying into the smaller object and only allocating one extra clone, which I&#39;ll implement soon.</div>

<div>

<div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><font color="#888888"><br>




<br>
<br>
Levente</font></span><div><div><br>
<br>
On Sat, 21 Sep 2013, <a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a> wrote:<br>
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
 Eliot Miranda uploaded a new version of VMMaker to project VM Maker:<br>
<a href="http://source.squeak.org/VMMaker/VMMaker.oscog-eem.399.mcz" target="_blank">http://source.squeak.org/<u></u>VMMaker/VMMaker.oscog-eem.399.<u></u>mcz</a><br>
<br>
==================== Summary ====================<br>
<br>
Name: VMMaker.oscog-eem.399<br>
Author: eem<br>
Time: 20 September 2013, 6:28:56.308 pm<br>
UUID: 89f8fefe-b59d-42d7-9c11-<u></u>7f848d0e5131<br>
Ancestors: VMMaker.oscog-eem.398<br>
<br>
A few isIntegerObject:&#39;s =&gt; isImmediate:&#39;s in primitives.<br>
<br>
More protocol.<br>
<br>
The Spur VM now draws its first window!!<br>
<br>
<br>
</blockquote>
A cheer goes up in the crowd of interested spectators.<br>
Probably lots still to do, but its a nice concrete milestone.<br>
Contributing is beyond me at this time, so I especially like to thank you for this important initiative.<br>
<br>
cheers -ben<br>
<br>
</blockquote>
</div></div></blockquote></div></div><br><br clear="all"><span><font color="#888888"><div><br></div>-- <br>best,<div>Eliot</div>
</font></span></div></div><span><font color="#888888">
<br></font></span></blockquote></div><span><font color="#888888"><br><br clear="all"><br>-- <br>Best regards,<br>Igor Stasenko.
</font></span></div></div>
</blockquote></div></div></div><div><div class="h5"><br><br clear="all"><br>-- <br>Best regards,<br>Igor Stasenko.
</div></div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>Best regards,<br>Igor Stasenko.
</div></div>