still no fun with invokedynamic

John Rose John.Rose at Sun.COM
Wed Sep 16 02:06:42 PDT 2009


το Sep 13, 2009, επι τῳ 6:53 AM, Rémi Forax εγραψα:

> Le 13/09/2009 02:38, John Rose a écrit :
>>
>> The backport a great option for experimentation, since it does not  
>> require a pre-release JVM.  Its performance seems to be comparable  
>> to the current MLVM JVM.  Basically what you get is a backend that  
>> performs JRuby-like rewrites of JSR 292 bytecodes.  As we work on  
>> code quality (JIT optimizer) in the MLVM JVM, I expect that the  
>> native JSR 292 implementations will be decisively faster, since the  
>> JSR 292 version of the code has (potentially) more quasi-static  
>> knowledge for the JIT optimizer to exploit.
>
> John, I don't agree with you :)
> The backport provide you more than the JRuby-like optimisation,
> or perhaps not more but something different.
>
> In fact the backport can be split in two parts, a part that is like  
> the JRuby optimisations on method calls, i.e an abstract class
> that contains one abstract method by arity. Another part, named  
> optimizer, works more like the indy compiler inlining patch,
> it is triggered when a method handle/call site is used often and try  
> to produce from the method handle adapter tree
> a simple sequence of bytecode that the VM JIT will be able to inline.

I had forgotten about the inlining part, which is very cool, and more  
than JRuby does.  (It's the job of the JVM or backport to do this kind  
of magic.)  So, I agree with your disagreement with me.  :-)

-- John


More information about the mlvm-dev mailing list