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.

Inlining heuristics

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 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:

JVMtime without JavaGO


time after applying JavaGO


Sun java interpreter from JDK 1.1.4258.332131.269
Microsoft jview (JIT)25.51610.094
Sun java from JDK 1.2 beta 4 (JIT)20.3309.213

It is also possible to optimize invocations of methods of system classes (from JDK class library). To do it just specify 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:

Look for new version at my homepage | E-mail me about bugs and problems