Brian Goetz wrote:
This code can be agressively optimized (including inlining, array bounds
check elimination, nonvirtualization, etc.) by a WAT compiler.. JC being
a perfect example. Not to mention the application itself. After all,
who only runs an application once? You can WAT compile the application
and then all of your code (except for anything loaded & run dynamically
at runtime) will run fast.
This argument neglects many of the benefits of JITs. First of all, you
can't inline virtual method calls effectively (at which point, you can
basically forget about optimizing) unless you know every class that is
going to be loaded, which you never do.
Modern JITs can make aggressive assumptions about inlining based on
current information and back them out if the information is later
invalidated (say, by another class being loaded.) Such speculative
optimizations are very effective.
JITs can also make better optimization decisions based on profiling data
gathered during interpretation. This is the JVM equivalent of branch
prediction -- by the time the code is compiled, the JVM has a lot of
information such as "how often is this branch taken" (which can be used
to make inlining space-vs-speed tradeoffs) and "how often is this lock
contended" (which can be used to make decisions about whether or not to
even try thin-locking.) And the list goes on and on.
Those are good points.. I'm not saying JIT is bad, I'm just saying
WAT has a place and can sometimes do things that JITs cannot because
of time constraints.
Moreover, in theory any optimization a JIT could perform, a WAT could
also perform, given the same information. E.g., profiling information,
or information about which classes are expected to be loaded.
Ideally, you'd have both!
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
