harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob <citi...@earthlink.net>
Subject JIT vs. WAT
Date Thu, 12 May 2005 12:55:12 GMT
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.

View raw message