Still crashity crashing

Rémi Forax forax at univ-mlv.fr
Wed Aug 5 08:43:35 PDT 2009


Le 05/08/2009 03:17, Charles Oliver Nutter a écrit :
> On Tue, Aug 4, 2009 at 8:16 PM, Rémi Forax<forax at univ-mlv.fr>  wrote:
>    
>> - remove the assertion that invokedynamic can only appear
>>    in class 1.7 compatible (version 51.0) class,
>>    currently your classes are not compiled with version 51.
>>    BTW, John, It should not work with the JSR 292 RI too ?
>>      
>
> Yes, ASM allows us to emit invokedynamic, and we always default our
> generated bytecode to whatever version of JVM we're running on, so
> it's possible we'll get a combination of<51 and indy if someone turns
> that flag on for a lower JVM (as in this case).
>
> We could certainly change that on our end too.
>    

Yes, It will avoid to crawle all classes but only the ones with 
invokedynamic.
So it will reduce the startup time.

>    
>> - optimize concurrently with the running program
>>    (hotspot do that, not the backport)
>>      
>
> In most cases we run code immediately after generating it, so we're
> not offloading compilation either. We'd probably want to consider
> doing that so that we wouldn't now have the additional cost of waiting
> for the backport to run.
>    

Yes.

>    
>> The main problem is that the backport is not able to optimize
>> the produced method handle tree.
>>
>> One problem is that the method InvokeDynamicsupport.pollAndGetClass is
>> private
>> but exported by PGC. The backport has the same contraint that
>> any Java code, so it is not able to optimize any method adapter tree
>> that contains PGC.
>>      
>
> Ahh...well I could certainly make it public if it would help the
> optimization. I understand that this is a natural limitation of the
> backport.
>    

Ok, the backport is now able to correctly optimize your code
(a stupid && instead of ||)
and i'm happy to say that the backport now performs better.

time bin/jruby --client 
-J-javaagent:../indy-backport/lib/jsr292-backport.jar 
-J-Xbootclasspath/p:../indy-backport/lib/jsr292-backport.jar 
-J-Djruby.compile.invokedynamic=true -J-Djruby.jit.logging.verbose=true 
bench/bench_fib_recursive.rb 100
real    0m45.438s
user    0m45.102s
sys    0m0.252s

time bin/jruby --client bench/bench_fib_recursive.rb 100
real    0m38.535s
user    0m38.239s
sys    0m0.168s

time bin/jruby --server 
-J-javaagent:../indy-backport/lib/jsr292-backport.jar 
-J-Xbootclasspath/p:../indy-backport/lib/jsr292-backport.jar 
-J-Djruby.compile.invokedynamic=true -J-Djruby.jit.logging.verbose=true 
bench/bench_fib_recursive.rb 100
real    0m38.887s
user    0m44.930s
sys    0m0.497s

time bin/jruby --server bench/bench_fib_recursive.rb 100
real    0m27.885s
user    0m27.645s
sys    0m0.197s

The next room of improvement is to directly put the bytecode weaver
of the backport at the end of the JRuby ASM compiler.
I hope this will reduce the startup time.

> - Charlie
>    

Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090805/60c50e38/attachment.html 


More information about the mlvm-dev mailing list