Compiling Java Just In Time
By Martin Heller
TechWeb Contributing Editor
August 28, 1996
In my boyhood, I learned that a scout is trustworthy, loyal, helpful,
friendly, courteous, kind, obedient, cheerful, thrifty, brave, clean,
and reverent. Recently, I learned that Java is simple, object-oriented,
distributed, interpreted, robust, secure, architecture-neutral,
portable, high-performance, multi-threaded, and dynamic.
That's Sun Microsystems' description, anyway. Of course, what seems
simple to James Gosling isn't necessarily simple to you or me. (Hey,
I've read some of Gosling's code....)
If Java were high-performance, you might think it could replace C++.
That's not yet the case, although it's not out of the realm of
possibility. ActiveX controls written in C or C++ and compiled to native
code currently outperform interpreted Java applets.
ACTIVEX IN THE KEY OF C++
-------------------------
Interpreters are, by their very nature slow, as everybody knows.
Well, Sun argues that Java has two things going for it: it's compiled
from sources (.java files) to byte-code or J-code (.class files) by
the developer, and the J-code can be compiled into native code at
run-time by the users Java Virtual Machine instead of being interpreted.
This second, optional compilation is referred to as occurring just in
time, and the piece of code that implements it is called a just-in-time
(JIT) compiler.
You can't expect a Java JIT compiler to speed up screen paints, because
they are typically limited by the speed of the graphics adapter and
not by anything happening in the computers CPU. You can expect a JIT to
speed up CPU-bound computations, especially in loops.
In the worst case, a Java applet or application might actually run
slower using a JIT compiler than it does interpreted. That would be the
case of an applet thats doing a lot of fancy graphics and almost no
arithmetic. In the best case, which is CPU-bound code in tight loops,
you can expect a JIT compiler to give you dramatic--perhaps
thousand-fold--speedups.
Can Java running with a JIT compiler be as fast as a native executable
such as an ActiveX control? Not really: it can come close, though. Java
is defined to be robust and secure, which means that the JIT compiler
can't avoid time-consuming little chores like having to check array
bounds and having to verify that security isnt being breached. In
addition, the JIT compiler itself takes some time to run.
C and C++ programs have to be compiled to native code before they can
run. Usually developers turn off the compiler's debugging features and
turn on all the optimization options once the products go to their
release phase. That makes C programs run as fast as possible, assuming
that they use the best algorithms and are coded reasonably well.
Of course, native code is not portable and Java J-code is portable, so a
C++ developer can't produce one version that runs on multiple platforms
like a Java developer can: its a tradeoff. Furthermore, J-code is
usually more compact than native code, so that Java applets usually
download faster than native-code applications like ActiveX controls or
Plug-Ins. Another tradeoff comes into play: ActiveX controls and
Plug-Ins are usually installed permanently once they're downloaded,
while Java applets usually live in the browsers cache temporarily and
are later discarded.
GETTING JIT COMPILATION
-----------------------
If you're a developer with a current Java tool set, you probably already
have a JIT compiler, no matter what tool vendor you favor. If youre
only using Java in your browser, you may or may not have a JIT compiler,
and it may or may not be turned on.
The retail versions of Netscape Navigator 3.0 and Microsoft Internet
Explorer 3.0 (IE) both have JIT compilers, and the compilers offer
similar performance. In IE, using the JIT compiler is an option which
can be turned on or off; youll find the checkbox for "Enable Java JIT
compiler" near the bottom of the Advanced Options tab.
When the box is checked, the JIT compiler is enabled; the setting
persists from session to session in the system registry. When IE loads,
it sets up its Java virtual machine; it decides at that time whether to
load the Java interpreter or the Java JIT compiler. If you change the
JIT option during an IE session, youll have to exit the session and
restart IE before the option will take effect.
JIT PERFORMANCE
---------------
In practice, turning on the JIT compiler in IE does about what
you'd expect: it speeds up computations but not graphics. Using the JIT
sometimes introduces a noticeable pause between the time the applet
finishes downloading and the time it starts to display; in my
experience, that pause is disconcerting--I wonder if something has
crashed--but less irritating than the download delay. On the whole,
though, Java applets running with the JIT compiler have a crisper feel
than the same applets running interpreted.
It's worthwhile to quantify the improvement. An independent company
doing Java development, Pendragon Software, has posted a little
benchmark suite called the Caffeinemark at
http://www.webfayre.com/pendragon
The tests are supplied as class files, GIF images, and HTML pages in a
67 KB ZIP file; you can download and run the tests locally, or run them
over the Internet.
Pendragon hasn't published their source code, which limits the faith I
put in their tests, but has published a database of results. I compared
the published results from two Pentium Pro machines running at 200 MHz,
one using IE 3.0 beta 1, which didn't include a JIT compiler, and one
using IE 3.0 beta 2, which did have a JIT compiler enabled. As you'd
expect, the CPU-bound tests were speeded up dramatically by the JIT
compiler, and the display-bound tests were not.
You need to take benchmark results with a grain of salt, even when they
confirm your expectations. What these benchmarks help you understand is
how the JIT compiler affects various types of code; to understand how it
will affect a specific applets performance, you either have to
understand what the applet is doing, or time the applet in controlled
circumstances.
Is Java executing with a JIT compiler live up to all its buzzwords? Is
it really both high-performance and interpreted? Now were mincing
words. Maybe the question is "When is an interpreter not an
interpreter?" In that case, the answer is "When it's a JIT compiler."