<div dir="ltr">Hi Armin,<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">We might again talk past each other. What I believe I understand<br>
behind what you're saying: you're looking at the outermost frame (the<br>one in which the looping occurs). This frame is not a virtualizable<br>(because you don't have any), and is also not a virtual (because it<br>
already exists before the loop). However, in simple examples, the<br>optimizer is able to remove all writes of the PC to it. But in larger<br>examples, these writes show up again. Is that correct?</blockquote><div><br>
</div><div>I'll try to make the example that Tim mentioned more clear.</div><div>Building up the deep stack was done INSIDE the loop. It was also the only thing that happened inside the loop.</div><div>That's why we expected the traces for deep and shallow stacks to be very similar - shouldn't the optimizer simply eliminate the additional frame objects?</div>
<div>Also, the relevant fields in the frame objects are indeed marked as virtualizable in the SPy VM.</div><div>The smalltalk code was basically this, with a varying argument to buildStack:</div><div><br></div><div>buildStack: depth</div>
<div> depth <= 0 ifTrue: [ ^ nil ].</div><div> self buildStack: depth - 1</div><div><br></div><div>100000 timesRepeat: [ self buildStack: 100 ]</div><div><br></div><div class="gmail_extra">Do you have any thoughts regarding this example?</div>
<div class="gmail_extra"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">In two words, a virtualizable object<br>
is not virtual at all; it's just an object in which some specific<br>fields are specially marked as "delayed", like the PC</blockquote><div class="gmail_extra"><br></div><div class="gmail_extra">Ok, so virtuals and virtualizables are two unrelated mechanisms?</div>
<div class="gmail_extra">How does the optimizer decide which writes to virtualizable fields it is able to eliminate? Is that based on a similar kind of analysis like the escape analysis for virtual objects?</div><div class="gmail_extra">
<br></div><div class="gmail_extra">Thanks, best regards,</div><div class="gmail_extra">Anton</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-30 11:13 GMT+02:00 Armin Rigo <span dir="ltr"><<a href="mailto:arigo@tunes.org" target="_blank">arigo@tunes.org</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Tim,<br>
<div class=""><br>
On 29 April 2014 13:22, Tim Felgentreff <<a href="mailto:timfelgentreff@gmail.com">timfelgentreff@gmail.com</a>> wrote:<br>
> Maybe it's useful to add that even without any changes to the SPy VM,<br>
> frame objects in loops are nicely virtualized in the tests (where they<br>
> are executing at a stack depth of 1), but already if we execute the<br>
> loop at a stack depth of 4 or 5, some frame attributes (but only some,<br>
> like the PC) suddenly appeared in the trace and were written all<br>
> over...<br>
><br>
> Frames failed to virtualize entirely at a stack depth of ~100<br>
><br>
> Part of these questions is that we're trying to understand why this occurs.<br>
<br>
</div>We might again talk past each other. What I believe I understand<br>
behind what you're saying: you're looking at the outermost frame (the<br>
one in which the looping occurs). This frame is not a virtualizable<br>
(because you don't have any), and is also not a virtual (because it<br>
already exists before the loop). However, in simple examples, the<br>
optimizer is able to remove all writes of the PC to it. But in larger<br>
examples, these writes show up again. Is that correct?<br>
<br>
This is expected so far. The writes to a normal, pre-existing object<br>
(the frame) can be delayed but only partly. I think that Topaz uses a<br>
hack for now to force the write of the PC to be delayed more: instead<br>
of writing the PC as an integer, it writes it as a small object<br>
containing an integer --- every time a new object. This is really a<br>
hack but it should solve the problem for now. You should discuss with<br>
Alex Gaynor if this hack turned out to work in the long run or if he<br>
eventually had to give it up and replace it with something else (like<br>
virtualizables).<br>
<br>
If your original question is precisely that you did all this already<br>
and want to learn more about virtualizables, then I'm sorry :-)<br>
Reading your original questions again seem to show some confusion<br>
(which might be on my side too). In two words, a virtualizable object<br>
is not virtual at all; it's just an object in which some specific<br>
fields are specially marked as "delayed", like the PC --- which can<br>
then be a regular integer, without the need for the small container<br>
object hack described above.<br>
<br>
<br>
A bientôt,<br>
<br>
Armin.<br>
</blockquote></div><br></div></div></div>