[pypy-dev] Virtualizables in RPython

Armin Rigo arigo at tunes.org
Wed Apr 30 20:21:53 CEST 2014


Hi Anton,

On 30 April 2014 13:11, Anton Gulenko
<anton.gulenko at student.hpi.uni-potsdam.de> wrote:
> Ok, so virtuals and virtualizables are two unrelated mechanisms?
> How does the optimizer decide which writes to virtualizable fields it is
> able to eliminate?

It's not decided by the optimizer.  A virtualizable structure has got
a static list of fields to handle (in _virtualizable_ = [...]).  When
we enter the JITted machine code, we have exactly one virtualizable
(the outermost frame), and we read the current value of these fields
in local variables (i.e. registers or machine stack locations).  When
we leave the machine code again, we write back the local variables
into the fields.  In the meantime, these fields have an outdated
value.  This only concerns the single outermost frame.  If there are
more frame objects created by the frame, their status as
"virtualizable" is completely ignored, and instead we simply rely on
the malloc-removal optimization called "virtuals".

What exactly occurs when one of these other frames escapes (following
the theory of Antonio) depends on yet another detail.  If each frame
has a normal "back" field, then escaping any frame will force all
frames below it to escape as well, which will force them all.  In PyPy
we solve this by using "virtualrefs", which is yet another concept,
unrelated to the two previous ones.  Each frame has a "f_back" field
which is not a normal reference to the previous frame, but
"jit.virtual_ref(previous_frame)".  This works a bit like a weakref,
except that it's not weak --- instead, it allows whatever is
referenced to remain virtual even if the small virtual_ref object
itself escapes, based on the assumption that most of the time we'll
not access the real object.


A bientôt,

Armin.


More information about the pypy-dev mailing list