Hi all, hi Charles, Playing with juby and the backport , I've found a mistake in the bootstrap code (in SimpleJavaBootstrap.java).
The bootstrap method first install a method named fallback that will later install the real method handle depending on the value of the first call to fallback. The problem lies in fallback, fallback can be decomposed in 3 steps, first find the most specific method, then use invoke_1..10 to get the return value and then set the target of the call site to the most specific method. The target is set *after* the call to the most specific method. With fib, because the function is recursive, this mean that the next call to fib will be done using the fallback and not the most specific method because it is not already installed and will be only when fib will return. In the particular case of the backport, because fallback is called often, the JIT of the backport JITs fallback and when fib returns it deoptimizes the call site to reoptimize it with the most specific method later. If you just permute step2 and step3, the program is 10% faster with client VM and more than 300% with server VM. SimleJavaBootstrap with no modification: [fo...@localhost juby]$ time /usr/jdk/jdk1.6.0_11/bin/java -javaagent:../indy-backport/lib/jsr292-backport.jar -cp .:src examples.fib 9227465 real 0m4.036s user 0m7.180s sys 0m0.111s SimleJavaBootstrap with step 2 and 3 permuted: [fo...@localhost juby]$ time /usr/jdk/jdk1.6.0_11/bin/java -javaagent:../indy-backport/lib/jsr292-backport.jar -cp .:src examples.fib 9227465 real 0m1.168s user 0m1.621s sys 0m0.059s This values are with the backport but I am sure you will gain something with jdk7. cheers, Rémi _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
