You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Bob <ci...@earthlink.net> on 2005/05/12 14:55:12 UTC
JIT vs. WAT
There's a lot of discussion on JIT vs. WAT. I think I can lay down
some framework on the issue.
First of all, we already have examples of both: Sun JDK 1.5 is a highly
evolved JIT, and GCJ 3 is a highly evolved WAT. In benchmarks, they
produce code that runs at comparable speeds. The speed advantage GCJ
gains by not having to compile at runtime (and by able to apply
time-intensive compilation optimizations), it loses by not having
runtime/profiling information available. Profiling is a pain, it's
unlikely most GCJ developers will ever use it.
That said, there are other pros and cons.
WAT-compiled code requires a smaller runtime system, their programs
load faster, they probably use less memory at runtime, and they run at
a (more) consistent speed. This makes WATs especially well-suited for
PDAs and other mobile devices, which may not have an extra few dozen
megabytes to spare for a full JIT-based Java system.
WATs also allow tighter integration with non-Java code: GCJ produces
object code fully compatible with C++. For this reason, GCJ's CNI
interface is really fast, while JNI can never be. If you wish to link
together a lot of Java and non-Java code as an integrated unit --- for
example, you wish to do Numerical Analysis using the standard LAPACK
libraries, or you wish to build a Swing front-end to an existing C/C++
program --- CNI will always be more satisfactory.
In general, WATs are very satisfactory for systems programming and
standard applications programming.
GCJ begins to fall short where you wish to use Java's dynamic
loading/linking capabilities. Classes must be loaded dynamically,
garbage collected when they're no longer used, and integrated with the
existing code. They must be bytecode-verified and sandboxed. I'm sure
that someone who's really clever could make this all work under GCJ.
But it essentially requires the "glueing together" of two very distinct
compilation models --- the static and the dynamic. And it is
unsatisfactory for many applications if the dynamically loaded code
behaves differently --- for example, runs 3-5X slower because it's
being interpreted. A fully dynamic fully JIT-based system seems
simpler and more likely to work well for these applications.
Finally, as of last summer, GCJ was not "drop-in" compatible with Sun's
javac. You cannot just take an Ant script and replace "javac" with
"gcj" and have it all work. With GCJ, you pretty much want to use the
GNU build tools. And if you wish to dynamically load any classes, that
requires additional tinkering. These are all issues that, in practice,
diminish GCJ's full Java compatibility.
In conclusion, I think there's room/place for both approaches. I'd
like to see Harmony develop a first-class JIT system, since GCJ has
already done a good job on the WAT approach.
Re: JIT vs. WAT
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Bob" == Bob <ci...@earthlink.net> writes:
Bob> There's a lot of discussion on JIT vs. WAT. I think I can lay down
Bob> some framework on the issue.
Bob> WAT-compiled code requires a smaller runtime system, their programs
Bob> load faster, they probably use less memory at runtime, and they run at
Bob> a (more) consistent speed. This makes WATs especially well-suited for
Bob> PDAs and other mobile devices, which may not have an extra few dozen
Bob> megabytes to spare for a full JIT-based Java system.
And, we think, desktop and small utility use, where the benefits of
reduced startup times and shared libraries are felt more strongly.
Bob> GCJ begins to fall short where you wish to use Java's dynamic
Bob> loading/linking capabilities. Classes must be loaded dynamically,
Bob> garbage collected when they're no longer used, and integrated with the
Bob> existing code. They must be bytecode-verified and sandboxed. I'm
Bob> sure that someone who's really clever could make this all work under
Bob> GCJ.
We've basically done all that in the gcc 4.0 release. There is a new
ABI that does all its linking at runtime (at some performance cost).
Verification works even for precompiled code. The origin of classes
is irrelevant; they are looked up in a shared library database; I like
to describe gcj as a "caching jit".
You can even run gcj itself as a jit (in response to an uncompiled
class, compile it to a .so that is then loaded), but this mode still
has some scalability problems. This does mean that, at the moment,
things like runtime bytecode instrumentation (AOP and friends) don't
mix that well with the gcj approach.
Bob> Finally, as of last summer, GCJ was not "drop-in" compatible with
Bob> Sun's javac. You cannot just take an Ant script and replace "javac"
Bob> with "gcj" and have it all work.
This is the role that the java-gcj-compat package fills.
jpackage-style alternatives basically solve all the problems in this
area.
Tom