Still crashity crashing

[Rémi Forax]

Le 04/08/2009 20:01, Charles Oliver Nutter a écrit :
> On Mon, Aug 3, 2009 at 10:25 AM, Rémi Forax<forax at univ-mlv.fr>  wrote:
>    
>> Hi Charlie,
>> I manage to be able to use the backport with you're code
>> but you really a rogue, you load your classes with the bootstrap classpath
>> (I suppose you bypass the verifier to start faster)
>> and guess what, by default, the backport doesn't take care about
>> classes loaded by the boot classpath.
>>
>> I think it's time to re-consider the default behaviour of the backport agent
>> :)
>>      
>
> Yeah, perhaps...but it's also perhaps reasonable that when people want
> the backport indy to work they would take the hit for startup. What
> other behavior are you considering?

- 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 ?

- optimize concurrently with the running program
   (hotspot do that, not the backport)

- change constant values triggering the optimizer

- change the algorithm inserting living objects in the bytecode:
   the current algorithm is pretty basic.

> Offline bytecode manipulation?
>    

Old dream. I don't know how to optimize invokedynamic
without having the target method handle which is a runtime value.

Nevertheless, the backport offers an ASM adapter that you can append
to your generator to avoid bytecode instrumentation (and the agent),
I will investigate that.


>    
>> But there is something more problematic,
>> the backport optimizer doesn't play well with your compiler :(
>>
>> time bin/jruby -J-Djruby.jit.logging.verbose=true
>> bench/bench_fib_recursive.rb 100
>> real    0m38.457s
>> user    0m38.115s
>> sys    0m0.164s
>>
>> time bin/jruby -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    4m51.625s
>> user    4m45.040s
>> sys    0m4.640s
>>      
>
> Yes, that's a pretty poor result :( Did you try moving JRuby to
> non-bootclasspath?
>    

I don't think, it's the real problem, it just take me time to figure out
why jruby was not able to find the backport support classes.

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.

I will investigate other problems later, it's 3am now :(

>    
>> Could you explain how the compiler works and what are these classes  ?
>>
>> agent
>> ruby/jit/ruby/home/forax/java/workspace/jruby_minus_1_dot_4_dot_0dev/lib/ruby/$1_dot_8/benchmark/format7681932_5430994
>> agent
>>      
>
> This is a jitted method body.
>
> ruby/jit/ruby/home/forax/java/workspace/jruby_minus_1_dot_4_dot_0dev/lib/ruby/$1_dot_8/benchmark/format7681932_5430994BlockCallback$block_0$RUBY$__block__xx1
>    
>> agent
>>      
>
> These are my generated method handles to closures.
>
> I will hopefully have some time soon to experiment with the backport myself...
>
> - Charlie
>    

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