JIT vs AOT Compilation

jg21 writes "This article on "Penguin-Driven" JVMs takes a look the performance of Java GUI applications based on the JFC/Swing API, and contends that the JIT-powered JVMs can't match a JVM with an ahead-of-time compiler ported to the Linux/x86 platform. With AOT compilation, says the CTO who has written this piece, real-world Swing applications performed perceivably faster. One is left wondering, will we now see the 'microbenchmark war' carried into the Linux camp?"

Comments

Re:Why Not Both?

[breadbot]

That's an interesting suggestion. I think it would be tough to pull off because, in order to detect hot spots, you need performance metrics. Compiled code that generates metrics on itself (for example, running with embedded profiling tools) is usually very slow. To take advantage of pre-compiling, you'd basically need a profiler with as little speed penalty as possible.

Also, it may turn out to be easier to recompile based on the original bytecode rather than the compiler machine code. Which would mean you'd have to ship both versions with every binary, unless the machine code was JIT'd at runtime.

On the other hand, if you had a way to optimize the already-compiled code, then heck, you'd have a general-purpose application accelerator. I think I remember reading, a few years ago, about research group at HP that started out working on aggressive processor emulation techniques and ended up with an optimizing recompiler. They were surprised to found that, when they targeted the same processor that the original binary came from, their application sped up 10-20% thanks to optimizations they could apply that the compiler couldn't have known about (cross-library inlining, for example).

Let me clarify

[p3d0]

If you can show me a commercial JIT compiler that doesn't already do this, I'll eat my hat. What you call "dynamic compilation" is so routine and mundane that when people talk about "JIT compilers" these days, that is exactly what they are talking about. Nobody blindly compiles on the first invocation of a method any more.

What you have mentioned is not the crux of the problem. I can't say much more because I do confidential work on IBM's JIT compiler.

Re:What's the point in Java bytecode anyway?

[p3d0]

It is parse trees. It's stack-based, which is pretty much just a post-order traversal of expression trees. Think of bytecode as a file format for describing expression trees.

Re:Introspective behaviour

[p3d0]

Think about usage patterns, maybe I am wrong but no actual VM execution model adapts program execution at running/history characteristics.

Yep, I think you're wrong. Look up "value profiling" for instance. It means finding values that are effectively constant on a particular run of a program, and recompiling that program on the assumption that the value will indeed be constant.

For instance, imagine the UNIX "wc" (word count) program were written in Java. An advanced JIT compiler could tell, for instance, that you have specified the "-l" option, and therefore you only need to count lines. The portions of the program that count letters and words would get removed as dead code, which probably speeds up the inner loop a great deal.

Moden JIT compilers produce self-profiling code, and then re-compile with the profiling information to produce a specialized version of the code that will run faster under the current conditions.

If that's not the "introspection" you're talking about, then perhaps I have misunderstood. Can you give an example?

Re:Why Not Both?

[Anonymous Coward]

You might want to look at LLVM. One of the ideas behind the project is to utilize information from the entire lifetime of the program to perform optimizations.