JavaGO performs global optimization of Java byte code with assumption
that it has information about all classes used in application.
By building inheritance graph of loaded class, JavaGO can locate
"final" classes, i.e. classes having no siblings in inheritance graph or,
in other words, classes which are not superclasses of some other classes.
All virtual invocations (invocations using dynamic binding at runtime)
of methods of such "final" classes can be replaced with non-virtual
invocations (using static binding) or even replaced with inline code of
these methods.
This optimization is correct only if there is a guaranty, that JavaGO
is provided with complete list of all classes and no more classes can be loaded
by application.
JavaGO uses a number of heuristics making decision whether to inline
"final" class method invocation or not. First of all it is size of byte code
of invoked method. JavaGO has -threshold options, which can be
used to specify maximal size of code for inlining. By default
value 64 is used.
Using only size of method as a hint for inlining, can cause inlining of
a large number of methods, including methods called very rarely (such as
Exception objects constructors, IO functions,...). JavaGO can use profiling
information to inline only these functions, which are frequently called and so
have high impact on total application performance. This can be done
using -profile option, which has two parameters: first is the
name of the profile file and second -
minimal value for method invocation counter.
Profile can be produced by JVM using -prof option.
If JavaGO makes a decision not to inline method, it can still do some
optimization by replacing virtual call instruction with non-virtual one
(which used to be executed faster because requires no dynamic binding).
Inlining proved to be very efficient optimization technic.
Performance of some artificial test programs is increased 2-3 times after
applying JavaGO. Benefits in performance are even higher with JIT compilers.
The following table summarize results of execution of
test program Test.java. This program performs
multiplication of matrices using getAt(), putAt() matrix class
methods to access matrix elements. Results were obtained at Pentium-II 250 MHz
PC with Windows NT 4.0:
| JVM | time without JavaGO (seconds) |
time after applying JavaGO (seconds) |
|---|
| Sun java interpreter from JDK 1.1.4 | 258.332 | 131.269 |
| Microsoft jview (JIT) | 25.516 | 10.094 |
| Sun java from JDK 1.2 beta 4 (JIT) | 20.330 | 9.213 |
It is also possible to optimize invocations of methods of system classes
(from JDK class library).
To do it just specify classes.zip file (or rt.jar)
with full pathname as one of JavaGo arguments. Certainly performance benefits
for real application will be not so significant.
Unfortunately, there is one significant restriction, which makes wide usage
if JavaGO impossible. Some JVMs perform by default verification
of loaded class files. For example, old versions of Sun's java by default
performs verification only of remote classes, but starting from JDK 1.2 beta 4
it verifies all classes if option -Xverify:none is not used.
And inline code violates some verification constraints: for example
inline method code can access protected components of another class, causing
verification error. Looks like in common case JavaGO can be used only with
verification option turned off or if all application classes belongs to the
same package. Class verifier from JDK 1.2 beta 4 also makes it impossible
for JavaGO to inline constructors and replace virtual calls with non-virtual.
JavaGO has special options -not-inline-constructor and
-not-use-invokespecial to disable such optimizations.
Option -not-inline-virtual prevents JavaGO from
inlining virtual methods (while it can still inline final and static methods)
and in conjunction with -not-use-invokespecial option makes
optimization performed by JavaGO really safe (such classes can be used with
other classes not presented to JavaGO), but looks like such optimizations
also can be done by Java compiler with -O option.
JavaGO is freeware and is distributed without any restrictions on
its usage. This is first version of the product, so it can contain
bugs which may cause incorrect code transformation. I will be glad to
receive replies, suggestions and bug reports from you at the following
address:
Konstantin.Knizhnik@digital.com
Look for new version at my homepage |
E-mail me about bugs and problems