Celebrity Compilers - Introduction to Compiler Construction in a Java World - page 284

FIGURE 8.2 Possible paths a Java program takes in GCJ.
Compiled Java programs are next fed into the GCJ back end to be optimized and
executed. The GCJ back end and the philosophy behind it are discussed in the next section.
8.4.2 GCJ in Detail
In addition to providing a Java implementation under the GPL license, a principal mo-
tivation for GCJ was to compete with JIT performance. As we saw in Section 8.2, JIT
compilation suffers from issues with start-up overhead and the overhead in detecting hot
spots.
GCJ took a \radically traditional" approach to overcome these problems and followed
the classical ahead-of-time (AOT) compilation, where bytecode programs are compiled into
a system-dependent binary before executing the programs.
GCJ developers treated Java like another form of C ++ . Java programs are translated to
the same abstract syntax tree used for other GCC source languages. Thus, all existing op-
timizations, like common sub-expression elimination, strength reduction, loop optimization
and register allocation, that were available for GNU tools could be used in GCJ [Bothner,
2003].
As a result, programs compiled directly to native code using the GCC back ends run at
full native speed with low start-up overhead and modest memory usage. This makes GCJ
a suitable compiler for embedded systems.
On the other hand, after start-up, Java programs compiled by GCJ do not necessarily
always run faster than a modern JIT compiler like HotSpot. There are various reasons for
this:
First of all, some optimizations possible in JIT compilation, such as run-time profile-
guided optimizations and virtual function inlining, are not possible in GCJ.
Programs that allocate many small, short-lived objects can cause the heap to fill
quickly and are garbage collected often, which in turn slows down the execution.
GCJ has sub-optimal run-time checking code, and the compiler is not so smart about
automatically removing array checks. A (dangerous) hack for this can be compiling
with GCJ's --no-bounds-check option.
On many platforms, dynamic (PIC 8 ) function calls are more expensive than static
ones. In particular, the interaction with Boehm BC seems to incur extra overhead
8 Position-independent code (PIC) is machine instruction code that can be copied to an arbitrary location
in memory and work without requiring any address relocation. PIC is commonly used for shared libraries.