[pypy-dev] is anyone actively hacking on the JVM backend?

Antonio Cuni anto.cuni at gmail.com
Fri Nov 30 10:38:00 CET 2007


Niko Matsakis wrote:
> Right now it's mostly in the JVM backend, though I had to insert a few 
> hooks into oosupport.  I wasn't sure whether the CLI had the same 
> "interlinking" problem.  

yes, the problems are nearly the same for the cli backend; basically, we 
want:

  1) to raise RPython exception from C#/Java code

  2) to create records with a specific set of fields

Right now the solution for (1) is very hackish: I have a stub file 
called main.exe which contains dummy functions to raise exceptions; 
pypylib.dll is compiled against main.exe, but then we compile the real 
executable so at runtime pypylib.dll is linked to a new main.exe which 
contains functions with the same name&signature as the dummy ones. 
Basically, we have a circular dependency between pypylib.dll and 
main.exe; believe it or not, in .NET it works :-).

I know, this solution is very ugly and moreover it forces the executable 
to be named main.exe. Interlink sound a much better approach :-).

For (2), the current solution is to write the records we want directly 
in C#/Java, and let the backend to special case those when rendering the 
name.
Unfortunately, I can't see a general solution here; the interlink 
approach works only for records which you only need to create and not to 
manipulate, but e.g. it can't work for StatResult because you still need 
to set individual fields after its creation. I guess this is the cause 
why StatResult is still implemented "the old way" in genjvm.

> I can look into whether more of the code could 
> be pulled into oosupport, but if I recall the two main places I had to 
> add hooks were:
> 
> 1. When rewrite the opcode table, I check now if the action for an 
> opcode is a virtual method: if so, instead of rewriting it to 
> "PushAllArgs, Invoke Method, Store Result," I rewrite it to: "Push PyPy 
> object, PushAllArgs, Invoke Method, Store Result."

Uhm... sorry, I can't see why this is necessary; could you explain a bit 
more in detail please?

> 2. I added prepare_ hooks for oostring, oounicode, and primitives, which 
> basically just push the receiver object.
> 
> We could probably pull more into oosupport, particularly if it gained 
> the ability to talk about static fields and things.

That would be nice; it would be a nice sprint topic, if only there were 
a sprint planned soon :-).

ciao Anto




More information about the Pypy-dev mailing list