[pypy-dev] Virtualizables in RPython

[Tim Felgentreff]

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.

cheers,
-Tim

On 28 April 2014 14:30, Anton Gulenko
<anton.gulenko at student.hpi.uni-potsdam.de> wrote:
> Dear Armin,
>
> thank you for your reply!
> I was not aware of the distinction between virtuals and virtualizables. It's
> a good start to have that covered ;)
> I thought marking frame objects as virtualizables was a necessary input for
> the optimizer, because it cannot decide everything on its own.
> Since you are calling virtualizables a hack, it seems the optimizer SHOULD
> be able to handle frame objects without additional hints. Could you explain
> why it is not able to do so?
>
> My original question was referring to virtuals, but I thought that frame
> objects were part of that. Now that I know of the distinction, I would like
> to understand both concepts in detail, and how they interact.
> I'm not sure how much of this I can ask you to describe to me - probably I
> should just read and debug the according code? Any suggestions?
>
> The motivation for this exercise is that the Spy VM is producing JIT traces
> that I (we) did not understand. For example, changes in the VM that seemed
> totally unrelated, were breaking the "virtualizablility" of frame objects
> (or parts of them), like by setting the program counter on each loop
> execution (inside the trace!).
> I'm not sure if this was unwanted behavior on behalf of the optimizer, but
> it seemed pretty non-deterministic, and I would like to understand the
> mechanism well enough to troubleshoot and optimize these traces.
>
> Best,
> Anton
>
>
>
> 2014-04-26 9:10 GMT+02:00 Armin Rigo <arigo at tunes.org>:
>
>> Hi Anton,
>>
>> On 24 April 2014 12:38, Anton Gulenko
>> <anton.gulenko at student.hpi.uni-potsdam.de> wrote:
>> > appreciate your input. I want to collect details about the underlying
>> > concept, and also about the specific implementation in the RPython JIT.
>> > For
>> > example, was this concept first introduced in Pypy, or is it an older
>> > idea?
>> > How exactly does the optimizer decide which objects can be virtualized,
>> > and
>> > which can not?
>>
>> We first need to clarify some details.  Are you talking about
>> "virtualizables", or "virtuals"?  These are two very different
>> concepts.  The latter is a very strong form of escape analysis, and
>> probably the single most efficient concept we have in the RPython JIT.
>>  The former, on the other hand, is more of a hack that was added at
>> some point in time, and that we're trying to remove --- unsuccessfully
>> so far, because it gives slighty better results than virtuals only,
>> for the specific use case where it works.
>>
>> I'm unsure which one you're talking about: only the frame object is a
>> "virtualizable", and it's not the job of the optimizer to decide that;
>> it's explicitly marked in the jitdriver.  See
>> https://pypy.readthedocs.org/en/latest/jit/virtualizable.html .  On
>> the other hand, if you're talking about "virtuals", then indeed we
>> have code in the optimizer to handle them.  It's some kind of escape
>> analysis leading to allocation removal.
>>
>>
>> A bientôt,
>>
>> Armin.
>
>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>