[pypy-dev] Need some pointers on my interpreter

Armin Rigo arigo at tunes.org
Wed Aug 15 17:38:18 CEST 2012


Hi Timothy,

On Wed, Aug 15, 2012 at 5:45 AM, Timothy Baldridge <tbaldridge at gmail.com> wrote:
> So I've been playing around with this for about a day now, and I guess I
> don't understand the "vritualizable" requirements.

I also tried (although for 15 minutes only), but I gave up because the
style is really too different from what we use in the Python
interpreter.  You have only one instance of Interpreter, and only one
list that stores local variables for all functions.  It's not really
possible to have it work well with PyPy's JIT as far as it is now: it
cannot at the same time "virtualize" the places near the top of the
list (because that's where variables are currently accessed) and keep
the rest of the list concrete.

Instead, what we do in PyPy's Python interpreter is to have one Frame
class per function, which is the obvious place to store a list of
*this function*'s local variables.  This would be what you need to
mark "virtualizable".

Closer to the style you are using is our regexp engine
(pypy.rlib.rsre.rsre_core).  It is based on only one
"Interpreter"-like instance (in this case StrMatchContext) and has
recursive invocations of the "interpreter main loop" using the same
MatchContext instance.  Looking for similarities, it declares as
"greens" some attributes of this MatchContext (greens = [...,
"ctx.pattern"]), which is a more efficient way than doing
greens=["ip"] followed by "ip = self._ip" in the jit_merge_point.  But
it doesn't have any notion of storing all local variables of all
frames of execution.  At most it stores the regexp's marks, which is
also a stack, but creating this stack is not optimized.  I'm unsure if
that model can work at all in your case without major efforts in the
jit front-end.


A bientôt,

Armin.


More information about the pypy-dev mailing list