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 <[email protected]> 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 <[email protected]>: > >> Hi Anton, >> >> On 24 April 2014 12:38, Anton Gulenko >> <[email protected]> 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 > [email protected] > https://mail.python.org/mailman/listinfo/pypy-dev > _______________________________________________ pypy-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pypy-dev
