| TurboJ
Java to Native Compiler |
What's new
-
TurboJ obtains an award
at Java One 2000
as Best Embedded Java Product June 2000
-
Added Availability, Products
and Slide
show December 2, 1999
-
Hewlett Packard introduces TurboChai
for ChaiVM - March 2, 1999
"... An Ahead-of-Time Compiler That Boosts Java Application Performance
Up to 20 Times Faster ..."
-
WindRiver announces TurboJ
for Personal JWorks - February 8, 1999
"... Improves performance of Java applications by more than 10 times
..."
Availability and ports
Silicomp sells TurboJ as a technology to Java Virtual Machine providers
rather than as a product for specific JVMs and OS environments. If you
are such a provider and interested in this technology please contact
us.
Products
TurboJ is available from our following partners:
-
TurboChai
for ChaiVM
from Hewlett Packard
-
TurboJ
for Personal JWorks
/ VxWorks from
WindRiver
Systems
-
TurboJ
for JAE
/ Reliant
Unix from Fujitsu/Siemens
Summary
Turbo is a Java (TM) byte code to native
code AOT (Ahead Of Time) compiler. Like a JIT compiler (and unlike
traditional compilers) it does not require the application source code,
it directly compiles the Java byte code. Unlike a JIT compiler, it works
as a separate compiler from the Java runtime and it achieves application
wide optimizations, gaining efficiency over JIT compiled code.
Rationale
Not only Java has gained a wide popularity on the desktops but also in
the embedded world. Nevertheless, in most implementations today the Java
byte code produced by the Java source compiler is simply interpreted. The
present byte code interpreters for Java execute applications at a performance
level 10 to 50 times slower than similar C++ applications, which is acceptable
in some cases, but unacceptable in others (e.g. multi-media applications).
To reach a better performance, a number of implementations are translating
the byte code on the fly as it is downloaded from the network, by JIT "Just-In-Time"
compilers. The advantages of JIT implementations are:
-
relatively fast translation;
-
improved performance (average of 6-12 times faster than interpreted code).
The disadvantages are:
-
few optimizations, only local "peephole" ones;
-
no provision for saving the generated code, since it is not created as
a relocatable binary;
-
no provision for sharing the translation with other users on the same system;
-
consumes CPU cycles and memory within the Virtual Machine;
-
still far from the potential parity with C++ implementation.
However, to be broadly accepted as a general purpose portable programming
environment, Java implementations must achieve performance close to, or
at parity with, conventional application development environments such
as C++.;
The TurboJ project
The TurboJ project is designed to develop a native Java compiler with full
optimization capabilities that:
-
transforms Java byte codes executed by the Java interpreter to native
executable code;
-
retains that executable code for subsequent usage;
-
has no application start-up penalty;
-
provides a performance superior to JIT compilers;
-
allows multiple users to share the results from the compiler;
-
allows the mix and match of both interpreted code and compiled code;
-
perform sophisticated optimizations at the application level.
The TurboJ compiler can also be viewed as an 'install' compiler for Java
applications. Many applications in the future will be distributed as Java
bytecode by software vendors. However users probably don't want to download
several megabytes of code and wait for JIT compilation each time they want
to run a spreadsheet. By using TurboJ, they can compile such an application
when installing it, which generates native code they can run each time
they need it (therefore using the byte code only as a platform independent
distribution format).
In addition, the TurboJ compiler is an optimizing compiler that performs
a number of optimizations that JIT compiler don't have time to do (since
the user is waiting for immediate execution, the compiler must execute
as fast as possible) whereas a few minutes of optimizations are worth at
installation time...
TurboJ architecture and implementation
The TurboJ implementation captures the Java byte codes for each class
as they are requested by the Java run-time system. However, instead of
loading them into memory for interpretation, the methods are translated
into machine binary code, using C as an intermediate representation.
Where possible, the TurboJ generated code does its work in-line, but
all of the facilities of the Java run-time system are required to run Turbo
compiled programs. In other words, TurboJ comes as an adjunct to the
native existing Java run-time system. TurboJ does not include its own
memory allocation, neither a garbage collector or a thread package. It
uses instead the native JDK (the platform's Java runtime distributed by
the platform vendor). The TurboJ technology currently operates as an adjunct
to Sun's Java run-time as it internally uses the JNI interface defined
by Javasoft, although it is designed to operate in conjunction with other's
Java run-time.
One other advantage is that TurboJ supports mix and match of interpreted
code and compiled code. Users can run in the same environment interpreted
programs, compiled programs, or programs that include both compiled classes
and interpreted classes.
Any Java application which can be run in the interpreter mode by that
system can also run in TurboJ mode. The TurboJ generated code still retains
all of the run-time checks required to conform to the Java semantics (e.g.
array bounds checking), in order to assure that the safety model for Java
is not violated. However, it looks for opportunities to remove redundant
checks.
In order to be totally portable, the TurboJ compiler is written in
Java (which also provides a stress test as our first test is to compile
the compiler itself) and it generates ANSI-C source code. In addition to
be a completely portable solution, the choice of generating C code instead
of machine code directly allows us to take advantage of existing optimizers
for multiple architectures. In particular, hardware platform vendors all
provide C compilers that are specifically tuned to generate high performance
code on their architecture (i.e. Arm, HP-PA, Intel, PowerPC, SPARC, etc.).
As TurboJ produces C code that lends itself to C compiler optimization
we can leverage out of the architecture specific optimizations that would
be difficult to reproduce for a large set of those.
New Developments
The new features that we want to add in the next releases are:
-
Provide additional performance boost. In particular, with the Hot Set technology,
take advantage of profiling results to better compile applications.
-
Take advantage of most recent results in compiler theory. Since a couple
of years, there have been significant advances in compiler techniques developed
in various Universities and Research Centers that we want to integrate
into our compiler.
-
Provide more options to generate smaller code size for embedded systems.
If you are interested in partnership with Silicomp on this technology,
please contact our Java Program
Manager.
Please send comments related to our web pages to: our
web master
Last modified : Thursday, 02-Dec-1999 17:38:20 CEST