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