Once I actually found the article it was an interesting read. However, this website looks *terrible*. When a column is only 11 characters wide due to advertising squishing it down, it is time to find some other magazine to read.

To angel'o'sphere:

1)

>>A VM based on a JIT compiler loads always only byte code
>>and compiles the byte-code to native code on the fly
>>depending on several algorithms/heuristics.
>>A AOT compiler does JUST THE SAME on the first invocation
>>of the byte code program, but it saves the generated
>>native code to be available for later invocations of the
>>same program. So for the later invocations, the
>>compilation was ahead of time, not for the first one

The thing you are talking about is called Caching JIT compilation (at least HotSpot and BEA engineers called it so when I talked with them at JavaOne 2004)

Besides, Caching JIT compilation does not occur on the first invocation - it would take long long time and miss profile information useful for optimizations.

2)

>>The Excelsior JET is no AOT compiler but just a static
>>compiler. However they seem to jump on the bandwagon
>>of a new buzzword, because the term AOT is only used
>>in academic circles currently

visit [visit link] (GNU compiler for Java). It's described as an AOT compiler...

3)

>>The next flaw is this: they measure a GUI application
>>over only 600 "loops". As the exact form of the loop
>>is not published, I have the impression they made the
>>loop in a way that a "standard" HotSpot JIT does
>>predictable not even attempt to compile much of the
>>covered code

In this test, HotSpot shows 28,9 frames/sec for short-running configuration and 44,6 frames/sec for long-running one. It does not look like "not even attempt to compile much of the covered code". Increasing the number of iteration to open more frames does not improve the HotSpot results. BTW, did you ever open 600+ frames in a Java application?

4)

>>In the "benchmark" of the article,
>>you neither have a loop (that one is in the external
>>driver program hidden) nor stack samples which occur
>>often enough to cause a JIT compilation.

Check the source code of the benchmark. It includes the loop

for(int j=0;j demo.createInternalFrame(..

so call stack chains are always rooted at the single method demo.createInternalFrame and then control goes to Swing.

5)

>>IMHO: the Excelsior people tricked the HotSpot/JIT VMs
>>in not doing their job, and thus you see the big
>>performance gain.
>> There are other tricks thinkable, e.g. not using
>>the standard SWING library but a tweaked one,
>>just remove some "synchronized" keywords if
>> you are sure the benchmark does not need them,
>> and voila ...

The standard Swing library and the public JET version were used for benchmarking. As for "synchronized" keywords - some of them are *safely* removed by the JET compiler during the course of escape analysis. There is excellent literature about this optimization technique (for example, see ACM OOPSLA'99 - about 5 papers were devoted to it).

Take care,

--Vitaly

P.S. JITs work well on servers and reusing the same machinery on the desktop is not always appropriate.

I don't like the article.
For several reasons I think they cheated and they coin old terms into new terms for no reason (except publicity). E.g. they mix up AOT with static compilation.
AOT is an extension of JIT compilation, and not a compilation done ahead of the first execution.
A VM based on a JIT compiler loads always only byte code and compiles the byte-code to native code on the fly depending on several algorithms/heuristics.
A AOT compiler does JUST THE SAME on the first invocation of the byte code program, but it saves the generated native code to be available for later invocations of the same program. So for the later invocations, the compilation was ahead of time, not for the first one.
The Excelsior JET is no AOT compiler but just a static compiler. However they seem to jump on the bandwagon of a new buzzword, because the term AOT is only used in academic circles currently (besides that Java 5.0 tries to cash compile informations and even native code over invocations).
The next flaw is this: they measure a GUI application over only 600 "loops". As the exact form of the loop is not published, I have the impression they made the loop in a way that a "standard" HotSpot JIT does predictable not even attempt to compile much of the covered code.
To understand that you have to know how a HotSpot JIT works. Two "big" strategies are used: fiddling with loops, this is a short code fragment, inside of one method, consider it as a for loop or while loop. You can do different things with it ... not interesting here.
The second big thing is call stack sampling. Suppose you have very often the method calls A, B, C on the call stack, the VM decides to check if anything can be inlined or if any of those methods is jitted.
In the "benchmark" of the article, you neither have a loop (that one is in the external driver program hidden) nor stack samples which occur often enough to cause a JIT compilation.
Excellent literature about JIT compilation and strategies can be found here: [visit link] tml and here: [visit link] /info/papers.shtml
IMHO: the Excelsior people tricked the HotSpot/JIT VMs in not doing their job, and thus you see the big performance gain. There are other tricks thinkable, e.g. not using the standard SWING library but a tweaked one, just remove some "synchronized" keywords if you are sure the benchmark does not need them, and voila ...

combining the two approaches will lead to overhead similar to a JIT approach (hence, there's nothing to be gained for a long-running program)

Why compare JIT against AOT? Why not have both?

AOT compilation makes for fast start up time and fast run time. JIT advocates claim that it can lead to better performance, as more optimizations can be performed with run-time information. So why not combine the two? Compile it before the first run, and further optimize it at run-time where appropriate. That way, you get the best of both worlds.