>> 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 >> Python and a Smalltalk interpreter into the same JVM. These >> static fields 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 class per generated interpreter and use non-static- >> methods instead, which should be better. > > I think this new feature is very cool. Is the logic for all the > InterLink stuff in jvm or in oosupport? I think it would be nice to > reuse the same ideas also for the cli backend.
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. 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." 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. Niko _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
