[pypy-dev] Compiling PyPy interpreter without GC

Armin Rigo arigo at tunes.org
Sat Mar 21 09:39:08 CET 2015


Hi Kunshan,

On 20 March 2015 at 04:16, Kunshan Wang <kunshan.wang at anu.edu.au> wrote:
> (...) Others (including PyPy) build a whole new VM,
> doing everything from scratch. There are many "high-performance VM"
> projects like PyPy (LuaJIT, v8, JavaScriptCore, HHVM to name a few), but
> the most important low-level parts (JIT, GC, ...) are not reused.

Nice to see a project that is similar to PyPy...  even though you seem
to have missed that point :-)  PyPy is based on RPython, whose goal is
also to provide a generic implementation substrate for any
interpreter-based language, by providing a general GC and a
meta-tracing JIT.  For that reason I would not put PyPy in the same
bag as LuaJIT, V8 and HHVM.  There are a number of very different
languages that already exist on top of the RPython architecture; PyPy
(the Python implementation) is only the most well-known.

Unlike Mu, the RPython toolchain was co-developed with PyPy, and so is
a bit more specifically suited for languages that share some
characteristics with Python (for example, multithreading is quite
limited).  Also, the separation between the two layers does not come
with (e.g.) a nice intermediate file format produced from the source
interpreter and fed to the RPython toolchain.

It is certainly interesting to see what kind of results you'd get by
feeding the "rtyped but not GC-transformed" instructions from RPython
to the Mu platform.  Again, I would recommend to start with smaller
things than the whole PyPy.  You can go about it in a test-driven way
by starting from, say, the simple examples in
rpython/translator/c/test/test_typed.py, and then pick the Prolog
interpreter at https://bitbucket.org/cfbolz/pyrolog/ as a much-smaller
first complete example.


A bientôt,

Armin.


More information about the pypy-dev mailing list