Le 04/08/2009 20:01, Charles Oliver Nutter a écrit :
On Mon, Aug 3, 2009 at 10:25 AM, Rémi Forax<fo...@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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
