what's John doing?

John Rose John.Rose at Sun.COM
Mon Aug 4 14:51:07 PDT 2008

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20080804/d0d43546/attachment.html 

More information about the mlvm-dev mailing list