[pypy-dev] ideas for Google Summer of code

Antonio Cuni anto.cuni at gmail.com
Thu Mar 17 22:26:55 CET 2011

On 17/03/11 21:25, Dan Stromberg wrote:
> On Thu, Mar 17, 2011 at 10:23 AM, Leonardo Santagada <santagada at gmail.com
> <mailto:santagada at gmail.com>> wrote:
>     7 - make pypy on .net jit work (or on java)

this is probably a too large task for GSoc. For one, before working on the JIT
it is necessary to make normal translation working, because right now ootype
backends are broken.  IIRC, it's not too hard because it consists of porting
virtualrefs to ootype, which should be simple. But it is possible that there
are other issues after that, since ootype translations have not run since a
long time (more than 1 year, I think).

About the JIT: JIT on .NET is not going to be any fast.  I did it for my
thesis when the JIT was more .NET friendly (no virtualrefs) and results were
interesting as a research project, but not good enough to be used in production.

The JIT for pypy-jvm is an open topic: the JVM has the potential to do a much
better job than the CLI, but we cannot know until we really try.

Having a working pypy-jvm-jit is a lot of work, though. It consists of:

1) make pypy-jvm (without jit) working again

2) design and implement a way to use Java objects at RPython level: this is
needed to write the backend

3) port the JIT to ootype again. Should not be too hard, but there are going
to be issues, because the codewriter has been heavily refactored since last
year, when the JIT on ootype worked well

4) write the backend

All together, it's probably huge for GSoc. But e.g 1+2 could fit it; we
already had a GSoc on this topic few years ago, but it didn't work well.

> This reminds me: it might be good to make the JVM PyPy be able to call native
> Java code - on a typical JRE, and on Android.  Last

yes, that's another interesting topic. It requires both points 1 and 2 above,
though. Once we have that, it should not be too hard, as it has already been
implemented for .NET and could use the same techniques (and probably reuse
also most of the code).


More information about the Pypy-dev mailing list