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:Introspective behaviour

[12357bd]

We need to go further, examine local execution instances, ie. I dayly run a given program (say Jedit), but I am only using/executing 50% of the code, and usually on a strongly patterned way. What about a JVM that detects that kind of behaviours and adapt itself ?.

That's why I am talking about 'introspective' programming, programs that continously examine how other/selfs programs are run and extract/apply usefull information.

Re:What about dynamic compliation?

[Anonymous Coward]

So far, all dynamic compilation advocates have managed to demonstrate is programs that - given a sufficiently long runtime, and we're talking weeks not minutes, are able through the use of dynamic optimisation to match the speed of traditionally compiled software.

That's quite impressive, considering that programs executing in virtual machines are generally at least an order of magnitude slower than machine code. But it doesn't make it a superior option, I'm afraid.

Not yet, anyway...

What's the point in Java bytecode anyway?

[RAMMS EIN]

Regardless of whether you use AOT or JIT compilation, if you're compiling anyway, what's the point in Java bytecode? I mean not why it exists, but why is it like machine code? Wouldn't it be more compact, quicker to interpret, and easier to optimize if it were higher level (say, like parse trees detailing the method invocations)?

Re:Why Not Both?

[OmniVector]

this is what i have been clamoring for for years. why don't we just cache JIT compilation information somewhere, and upon launching an application, check a hash of the system resources (memory, cpu, other information that aids to JIT compilation performance) and if the hash hasn't changed, just use the pre-JIT compiled binary information? and even if it DID change and the platform is still the same, why not keep the pre-JIT compiled information and redo the JIT compilation in the background?

something must be incredibly wrong with this idea, because it's such a stupid, simple, solution to the problems with JIT performance that clearly there's a reason Sun hasn't done it yet. but what do i know.. i'm just a 4th year CS undergrad.

Re:Introspective behaviour

[p3d0]

As you say, you end up with a slippery slope that leads to AOT compilation, which would be fine, except that it makes you ask the question, why are we jitting in the first place? At that point, whatever answers you come up with often work against keeping persistent data between runs of the same application.

However, it's certainly not impossible in principle, and I'm sure there are profitable points on the JIT-versus-AOT spectrum that have yet to be explored.