On May 28, 2008, at 2:12 AM, Charles Oliver Nutter wrote: > What else can we explore? What tools should we use to investigate?
You are already using LogCompilation, and that is the best way to understand the inlining decisions of the JIT. With these special patterns, you are perhaps verging on a need (often repeated by customers) to give advice to the JIT about inlining and other compilation decisions. If you could give simple advice to the JIT about what should be inlined, what would you tell it? The PrintAssembly feature (new in product builds) is your best view of the actual machine code. http://wikis.sun.com/display/HotSpotInternals/PrintAssembly This is the best way to find what the bottleneck really is, instead of treating the JIT as a black box. The catch with PrintAssembly is that you have to build (or borrow) the disassembly plugin. They are not yet widely available. You'd be an early adopter... I see two paths here: 1. Force the JIT to inline the code patterns you care about. (One logical Ruby method should be compiled in one JIT compilation task.) 2. Make the JVM process the exceptions you care about more efficiently, in the out-of-line case. Both should be investigated. Both are probably good graduate theses... Anyone? The easiest one to try first is #1, since we already have a compiler oracle, and could quickly wire up the right guidance statements (in a JVM tweak), if we could figure out what Ruby wants to say to the JVM about inlining. -- John _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
