[pypy-dev] Virtualizables in RPython

Armin Rigo arigo at tunes.org
Wed Apr 30 11:13:18 CEST 2014


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.


More information about the pypy-dev mailing list