[pypy-dev] Virtualizables in RPython

[Anton Gulenko]

Hi Armin,

We might again talk past each other.  What I believe I understand
> behind what you're saying: you're looking at the outermost frame (the
> one in which the looping occurs).  This frame is not a virtualizable
> (because you don't have any), and is also not a virtual (because it
> already exists before the loop).  However, in simple examples, the
> optimizer is able to remove all writes of the PC to it.  But in larger
> examples, these writes show up again.  Is that correct?


I'll try to make the example that Tim mentioned more clear.
Building up the deep stack was done INSIDE the loop. It was also the only
thing that happened inside the loop.
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?
Also, the relevant fields in the frame objects are indeed marked as
virtualizable in the SPy VM.
The smalltalk code was basically this, with a varying argument to
buildStack:

buildStack: depth
     depth <= 0 ifTrue: [ ^ nil ].
     self buildStack: depth - 1

100000 timesRepeat: [ self buildStack: 100 ]

Do you have any thoughts regarding this example?

In two words, a virtualizable object
> is not virtual at all; it's just an object in which some specific
> fields are specially marked as "delayed", like the PC


Ok, so virtuals and virtualizables are two unrelated mechanisms?
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?

Thanks, best regards,
Anton


2014-04-30 11:13 GMT+02:00 Armin Rigo <arigo at tunes.org>:

> Hi Tim,
>
> On 29 April 2014 13:22, Tim Felgentreff <timfelgentreff at gmail.com> wrote:
> > Maybe it's useful to add that even without any changes to the SPy VM,
> > frame objects in loops are nicely virtualized in the tests (where they
> > are executing at a stack depth of 1), but already if we execute the
> > loop at a stack depth of 4 or 5, some frame attributes (but only some,
> > like the PC) suddenly appeared in the trace and were written all
> > over...
> >
> > Frames failed to virtualize entirely at a stack depth of ~100
> >
> > Part of these questions is that we're trying to understand why this
> occurs.
>
> We might again talk past each other.  What I believe I understand
> behind what you're saying: you're looking at the outermost frame (the
> one in which the looping occurs).  This frame is not a virtualizable
> (because you don't have any), and is also not a virtual (because it
> already exists before the loop).  However, in simple examples, the
> optimizer is able to remove all writes of the PC to it.  But in larger
> examples, these writes show up again.  Is that correct?
>
> This is expected so far.  The writes to a normal, pre-existing object
> (the frame) can be delayed but only partly.  I think that Topaz uses a
> hack for now to force the write of the PC to be delayed more: instead
> of writing the PC as an integer, it writes it as a small object
> containing an integer --- every time a new object.  This is really a
> hack but it should solve the problem for now.  You should discuss with
> Alex Gaynor if this hack turned out to work in the long run or if he
> eventually had to give it up and replace it with something else (like
> virtualizables).
>
> If your original question is precisely that you did all this already
> and want to learn more about virtualizables, then I'm sorry :-)
> Reading your original questions again seem to show some confusion
> (which might be on my side too).  In two words, a virtualizable object
> is not virtual at all; it's just an object in which some specific
> fields are specially marked as "delayed", like the PC --- which can
> then be a regular integer, without the need for the small container
> object hack described above.
>
>
> A bientôt,
>
> Armin.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20140430/da4c49fc/attachment.html>