[pypy-dev] is anyone actively hacking on the JVM backend?
niko at alum.mit.edu
Thu Nov 29 21:52:26 CET 2007
Hopefully, these changes will not particularly affect anyone not
actively touching the jvm directory. The only changes in oosupport
are the addition of various "prepare_" methods to the Generator
class. These methods give the jvm backend an opportunity to push a
this pointer here and there, but for those methods I added a default
"do-nothing" implementation. For example, there is a
"prepare_call_primitive()" which is called before the arguments for a
primitive are pushed onto the stack.
I think that the oosupport code could probably be refactored, though
I'm not precisely sure how right now. Right now it is basically a
thin layer that extracts some useful information from the 'op' objects
and passes it to the generators; furthermore, it uses this stack-based
API which doesn't give much information to the backend about why
something is being pushed (i.e., is it a function argument? if so, to
what function? etc). This is ok as far as it goes, but maybe there is
something more elegant? As I said, I don't have any precise
suggestions right now, but it's something to think about.
On Nov 29, 2007, at 8:24 PM, amit wrote:
> Hi Niko,
> I am working on the "CLR" module --- ..pypy/module/clr/
> Just trying to play around with "interp_clr.py" and
> "app_clr.py" in there.
> Hope your commits will make it more better.
> Maciej Fijalkowski wrote:
>> As noone answers... I think amitReg is doing some CLI related
>> stuff, which means you can stomp on each other on oosupport, but
>> he's doing rather library integration, so sounds very unlikely.
>> Besides, I'm not aware of anyone.
>> On Nov 29, 2007 7:46 PM, Niko Matsakis <niko at alum.mit.edu <mailto:niko at alum.mit.edu
>> >> wrote:
>> I have been making small improvements to the JVM backend: I am
>> towards eliminating any remaining conformance problems, and also
>> towards fixing a few warts in the implementation.
>> Right now I am wringing out the last few bugs from a check-in that
>> would allow multiple PyPy-generated interpreters to be used
>> simultaneously. Currently, the code uses a few static fields that
>> would conflict if, for example, someone tried to load both a
>> and a Smalltalk interpreter into the same JVM. These static
>> were used to allow the helper code (src/PyPy.java and friends) to
>> create instances of exception classes and other RPython-generated
>> code. The new code creates a single instance of the PyPy helper
>> per generated interpreter and use non-static-methods instead,
>> should be better.
>> Anyway, I just want to be sure I am not stepping on anyone's
>> toes if I
>> check this in, since it makes small changes all over the place to
>> ensure that the proper PyPy object is pushed onto the stack, etc.
>> pypy-dev at codespeak.net <mailto:pypy-dev at codespeak.net>
>> pypy-dev at codespeak.net
More information about the Pypy-dev