[pypy-dev] Work on the JVM backend

[Antonio Cuni]

Hello Michał,

On 01/12/2012 09:24 PM, Michał Bendowski wrote:
> Hello everyone,  
> 
> Back in the summer I asked on this mailing list if there's interest in moving the JVM backend forward. Back then there was some enthusiasm, so I got back to it when I had the chance, which unfortunately was a few months later. The suggestion back then was to look into using JPype to integrate more closely with Java-side code, and that's what I would like to do.
> 
> But before that, I noticed that the JVM backend fails to translate the standard interpreter and spent some time lately getting to know the code and trying to get it to work. What I have right now is a version that outputs valid Jasmin files, which unfortunately still contain some invalid bytecodes (longs vs ints from what I've seen, I'll look into it next).

the long vs int problems are likely due to the fact that you are translating
on a 64 bit machine. The translator toolchain assumes that the "native" long
type of the target platform is the same as the source one, but this is not the
case if you are targeting the JVM (where long is 32 bit) on a 64 bit linux
(where long is 64 bit).

This problem is not easily solvable, so my suggestion is just to translate
pypy-jvm inside a 32bit chroot for now.

> It would be awesome if someone could take a look at my changes. What's the best way to submit them? Bitbucket pull requests? They will need to go through some review  - do you have a workflow for that?

we don't have any precise workflow, although a bitbucket pull request might be
the easiest thing to do. I'll be glad to review it.

> Here's a short list of stuff I found and fixed (hopefully):
> - support the ll_getlength method of StringBuilders in ootype,
> - make compute_unique_id work on built-ins (StringBuilders again).

not sure what you mean here. What is the relation between compute_unique_id
and StringBuilder?

> - provide oo implementations (or stubs) for pypy__rotateLeft, pypy__longlong2float etc.
> - handle rffi.SHORT and rffi.INT showing up in graphs. For now I try to emit something that makes sense (seemed easier), but the right solution is probably to see if the code in question (rbigint, rsha) can be implemented on the java level.

yes, this is another issue that has been around for a long time. In theory, we
would like to be able to write per-backend specific code which overrides the
default implementation. This would be useful for rbigint and rsha, but also
e.g. for rlib.streamio. However, we never wrote the infrastructure to do that.

> - handle the jit_is_virtual opcode - I had no idea how to "safely ignore" it for now, is False the safe answer?

yes. Look at translator/c/funcgen.py:848: this is how jit_is_virtual is
implemented by the C backend, you can see that it always returns 0/

> I hope someone can help me to submit the changes and maybe guide with further work.

Please put your work on bitbucket, I'll review it. I'd greatly appreciate if
you committed small checkins (one for each fix/feature you are doing) instead
of one giant commit with all the changes :-)

ciao,
Anto