On Jul 31, 2008, at 2:35 PM, Charles Oliver Nutter wrote:
At what point do you think
it would be worth trying to do an experimental test with e.g. JRuby,
wiring it in where reflection was being used previously?
Here are the upcoming points of development for the native (non-
emulated) JSR 292 RI:
1. direct emulation of invoke* instructions, interpreter only (first
cut done & pushed)
2. adapter and bound method handles, interpreter only (working on
this now)
3. invokedynamic (interpreter only)
4. compiler support for method handles
5. compiler support for invokedynamic
6. specialized call site optimizations (inlining)
7. specialized method handle optimizations (method handle compilation
and/or folding)
There are different advantages for integrating JRuby at each point.
1. can replace class generation for out-calls to Java (better
footprint and bootstrap, but missing full performance until 6, 7)
2. can replace class generation pertaining to accessors, Ruby
methods, linkage logic
3. can push linkage logic down into the JVM (more compact bytecode,
slightly better performance, but missing full performance until 6, 7)
4, 5. performance improvement from steps 2, 3
6. meet or exceed current performance for hot paths
7. meet or exceed current performance for warm paths
Early adoption is better, from my POV, but when you move in early you
have to be willing to live with non-working appliances, construction
noise, etc.
To answer your specific question, you can almost replace reflection
now, except for argument and return value transformations (adapting
boxed varargs to native calling sequences). You could either wire up
your own infrastructure for adapters to step 1 method handles, or
wait for step 2 to provide you with VM-native adapters.
I think the easiest way to do the adapters is to reflect argument
lists up to (privileged) Java code, which will edit them in place on
the interpreter stack. We'll see shortly if this works out. Backup
plan is to put tons of new code into the JVM to handle all the corner
cases of Integer.valueOf(int) and its dozens of cousins.
-- John
_______________________________________________
mlvm-dev mailing list
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
