Hi Tim, On 29 April 2014 13:22, Tim Felgentreff <[email protected]> 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. _______________________________________________ pypy-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pypy-dev
