το 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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
