Chapter 8 Continued: Performance Features and Tools

Print-friendly Version

[<<BACK] [CONTENTS] [NEXT>>]

The new Java Virtual Machines (VMs) have features to increase performance, and you can use a number of tools to increase application performance or reduce the size of generated class files. Such features and tools improve the performance of your application with little or no change required to your application.

• Java VM Features
• Just-In-Time Compilers
• Third-Party Tools

Java VM Features

The Java® 2 Plaftform release has introduced many performance improvements over previous releases, including faster memory allocation, reduction of class sizes, improved garbage collection, streamlined monitors and a built-in JIT as standard. When using the new Java 2 VM straight out of the box you will see an improvement, however by understanding how the speed-ups work you can tune your application to squeeze out every last bit of performance.

Method Inlining

The Java 2 release of the Java VM automatically inlines simple methods at runtime. In an un-optimized Java VM, every time a new method is called, a new stack frame is created. The creation of a new stack frame requires additional resources as well as some re-mapping of the stack, the end result is that creating new stack frames incurs a small overhead.

Method inlining increases performance by reducing the number of method calls your program makes. The Java VM inlining code inlines methods that return constants or only access internal fields.

Automatic VM inlining is illustrated using the following small example:

public class InlineMe {

    int counter=0;

    public void method1() {
        for(int i=0;i<1000;i++)
        addCount();
        System.out.println("counter="+counter);
    }

    public int addCount() {
        counter=counter+1;
        return counter;
    }

    public static void main(String args[]) {
        InlineMe im=new InlineMe();
        im.method1();
        }
}

In the current state the addCount method doesn't look very attractive to the inline detector in the VM because the addCount method returns a value. To find out if this method is inlined, run the compiled example with profiling enabled:

java -Xrunhprof:cpu=times InlineMe

This generates a java.hprof.txt output file. The top ten methods will look similar to this:

CPU TIME (ms) BEGIN (total = 510) 
                       Thu Jan 28 16:56:15 1999
rank self accum  count trace method
 1  5.88%  5.88%    1  25 java/lang/Character.
                            <clinit>
 2  3.92%  9.80% 5808  13 java/lang/String.charAt
 3  3.92% 13.73%    1  33 sun/misc/
                            Launcher$AppClassLoader.
                            getPermissions
 4  3.92% 17.65%    3  31 sun/misc/
                            URLClassPath.getLoader
 5  1.96% 19.61%    1  39 java/net/
                            URLClassLoader.access$1
 6  1.96% 21.57% 1000  46 InlineMe.addCount
 7  1.96% 23.53%    1  21 sun/io/
                            Converters.newConverter
 8  1.96% 25.49%    1  17 sun/misc/
                            Launcher$ExtClassLoader.
                            getExtDirs
 9  1.96% 27.45%    1  49 java/util/Stack.peek
10  1.96% 29.41%    1  24 sun/misc/Launcher.<init>

If you change the addCount method to no longer return a value, the VM will inline it for you at runtime. To make the code inline friendly replace the addCount method with the following:

public void addCount() {
        counter=counter+1;
}

And run the profiler again:

java -Xrunhprof:cpu=times InlineMe

This time the java.hprof.txt output should look different. The addCount method has gone. It has been inlined!

CPU TIME (ms) BEGIN (total = 560) 
                       Thu Jan 28 16:57:02 1999
rank self  accum  count trace method
 1  5.36%  5.36%    1  27 java/lang/
                            Character.<clinit>
 2  3.57%  8.93%    1  23 java/lang/
                            System.initializeSystemClass
 3  3.57% 12.50%    2  47 java/io/PrintStream.<init>
 4  3.57% 16.07% 5808  15 java/lang/String.charAt
 5  3.57% 19.64%    1  42 sun/net/www/protocol/file/
                            Handler.openConnection
 6  1.79% 21.43%    2  21 java/io/InputStreamReader.fill
 7  1.79% 23.21%    1  54 java/lang/Thread.<init>
 8  1.79% 25.00%    1  39 java/io/PrintStream.write
 9  1.79% 26.79%    1  40 java/util/jar/
                            JarFile.getJarEntry
10  1.79% 28.57%    1  38 java/lang/Class.forName0

Streamlined synchronization

Synchronized methods and objects have until Java 2 always incurred an additional performance hit as the mechanism used to implement the locking of this code used a global monitor registry which was only single threaded in some areas such as searching for existing monitors. In the Java 2 release, each thread has a monitor registry and so many of the existing bottlenecks have been removed.

If you have previously used other locking mechanisms because of the performance hit with synchronized methods it is now worthwhile re-visiting this code and incorporating the new Java 2 streamlined locks.

In the following example which is creating monitors for the synchronized block you can achieve a 40% speed up. Time taken was 14ms using JDK 1.1.7 and only 10ms with Java 2 on a Sun Ultra 1.

class MyLock {

  static Integer count=new Integer(5);
  int test=0;

  public void letslock() {
     synchronized(count) {
        test++;
     }
  }
}

public class LockTest {

  public static void main(String args[]) {

     MyLock ml=new MyLock();
     long time = System.currentTimeMillis();

     for(int i=0;i<5000;i++ ) {
      ml.letslock();
     }
     System.out.println("Time taken="+
      (System.currentTimeMillis()-time));
  }
}

Java Hotspot

The Java HotSpot VM is Sun Microsystem's next-generation virtual machine implementation. The Java HotSpot VM adheres to the same specification as the Java 2 VM, and runs the same byte codes, but it has been re-engineered to leverage new technologies like adaptive optimization and improved garbage collection models to dramatically improve the speed of the Java VM.

Adaptive optimization

The Java Hotspot does not include a plug-in JIT compiler but instead compiles and inline methods that appear it has determined as being the most used in the application. This means that on the first pass through the Java bytecodes are interpreted as if you did not have a JIT compiler present. If the code then appears as being a hotspot in your application the hotspot compiler will compiler the bytecodes into native code which is then stored in a cache and inline methods at the same time. See the inlining section for details on the advantages to inlining code.

One advantage to selective compilation over a JIT compiler is that the byte compiler can be spend more time generating highly optimized for the areas that would benefit from the optimization most. The compiler can also avoid compiling code that may be best run in interpreted mode.

Earlier versions of the Java HotSpot VM were not able to optimize code that was not currently in use. The downside to this is if the application was in a huge busy loop the optimizer would not be able to compile the code for area until the loop had finished. Later Java Hotspot VM releases use on-stack replacement, meaning that code can be compiled into native code even if it is in use by the interpreter.

Improved Garbage Collection

The garbage collector used in the Java HotSpot VM introduces several improvements over existing garbage collectors. The first is that the garbage collector is termed a fully accurate collector. What this means is that the garbage collector knows exactly what is an object reference and what is just data. The use of direct references to objects on the heap in a Java HotSpot VM instead of using object handles. This increased knowledge means that memory fragmentation can be reduced which results in a more compact memory footprint.

The second improvement is in the use of generational copying. Java creates a large number of objects on the heap and often these objects are short lived. By placing newly created objects in a memory bucket, waiting for the bucket to fill up and then only copy the remaining live objects to a new area the block of memory that the bucket used can be freed in one block. This means that the VM does not have to search for a hole to fit each new object in the heap and means that smaller sections of memory need to be manipulated at a time.

For older objects the garbage collector makes a sweep through the heap and compacts holes from dead objects directly, removing the need for a free list used in earlier garbage collection algorithms.

The third area of improvement is to remove the perception of garbage collection pauses by staggering the compaction of large free object spaces into smaller groups and compacting them incrementally.

Fast Thread Synchronization

The Java HotSpot VM also improves existing synchronized code. Synchronized methods and code blocks have always had a performance overhead when run in a Java VM. The Java HotSpot implements the monitor entry and exit synchronization points itself and does not depend on the local OS to provide this synchronization. This results in a large speed improvement especially to often heavily synchronized GUI applications.

Just-In-Time Compilers

The simplest tool used to increase the performance of your application is the Just-In-Time (JIT) compiler. A JIT is a code generator that converts Java bytecode into native machine code. Java programs invoked with a JIT generally run much faster than when the bytecode is executed by the interpreter. The Java Hotspot VM removes the need for a JIT compiler in most cases however you may still find the JIT compiler being used in earlier releases.

The JIT compiler was first made available as a performance update in the Java Development Kit (JDK) 1.1.6 software release and is now a standard tool invoked whenever you use the java interpreter command in the Java 2 platform release. You can disable the JIT compiler using the -Djava.compiler=NONE option to the Java VM. This is covered in more detail at the end of the JIT section.

How do JIT Compilers work?

JIT compilers are supplied as standalone platform-dependent native libraries. If the JIT Compiler library exists, the Java VM initializes Java Native Interface (JNI) native code hooks to call JIT functions available in that library instead of the equivalent function in the interpreter.

The java.lang.Compiler class is used to load the native library and start the initialization inside the JIT compiler.

When the Java VM invokes a Java method, it uses an invoker method as specified in the method block of the loaded class object. The Java VM has several invoker methods, for example, a different invoker is used if the method is synchronized or if it is a native method.

The JIT compiler uses its own invoker. Sun production releases check the method access bit for value ACC_MACHINE_COMPILED to notify the interpreter that the code for this method has already been compiled and stored in the loaded class.

When does the code become JIT compiled code?

When a method is called the first time the JIT compiler compiles the method block into native code for this method and stored that in the code block for that method.

Once the code has been compiled the ACC_MACHINE_COMPILED bit, which is used on the Sun platform, is set.

How can I see what the JIT compiler is doing?

The _JIT_ARGS environment variable allows simple control of the Sun Solaris JIT compiler. Two useful values are trace and exclude(list). To exclude the methods from the InlineMe example and show a trace set _JIT_ARGS as follows:

Unix:
export _JIT_ARGS="trace exclude(InlineMe.addCount 
                               InlineMe.method1)"

$ java InlineMe                                               
Initializing the JIT library ...
DYNAMICALLY COMPILING java/lang/System.getProperty 
                                  mb=0x63e74
DYNAMICALLY COMPILING java/util/Properties.getProperty 
                                  mb=0x6de74
DYNAMICALLY COMPILING java/util/Hashtable.get 
                                  mb=0x714ec
DYNAMICALLY COMPILING java/lang/String.hashCode 
                                  mb=0x44aec
DYNAMICALLY COMPILING java/lang/String.equals 
                                  mb=0x447f8
DYNAMICALLY COMPILING java/lang/String.valueOf 
                                  mb=0x454c4
DYNAMICALLY COMPILING java/lang/String.toString 
                                  mb=0x451d0
DYNAMICALLY COMPILING java/lang/StringBuffer.<init> 
                                  mb=0x7d690
 <<<< Inlined java/lang/String.length (4)

Notice that inlined methods such as String.length are exempt. The String.length is also a special method as it is normally compiled into an internal shortcut bytecode by the Java Interpreter. When using the JIT compiler these optimizations provided by the Java Interpreter are disabled to enable the JIT compiler to understand which method is being called.

How to use the JIT to your advantage

The first thing to remember is that the JIT compiler achieves most of its speed improvements the second time it calls a method. The JIT compiler does compile the whole method instead of interpreting it line by line which can also be a performance gain for when running an application with the JIT enabled. This means that if code is only called once you will not see a significant performance gain. The JIT compiler also ignores class constructors so if possible keep constructor code to a minimum.

The JIT compiler also achieves a minor performance gain by not pre-checking certain Java boundary conditions such as Null pointer or array out of bounds exceptions. The only way the JIT compiler knows it has a null pointer exception is by a signal raised by the operating system. Because the signal comes from the operating system and not the Java VM, your program takes a performance hit. To ensure the best performance when running an application with the JIT, make sure your code is very clean with no errors like Null pointer or array out of bounds exceptions.

You might want to disable the JIT compiler if you are running the Java VM in remote debug mode, or if you want to see source line numbers instead of the label (Compiled Code) in your Java stack traces. To disable the JIT compiler, supply a blank or invalid name for the name of the JIT compiler when you invoke the interpreter command. The following examples show the javac command to compile the source code into bytecodes, and two forms of the java command to invoke the interpreter without the JIT compiler.

  javac MyClass.java
  java -Djava.compiler=NONE MyClass

or

  javac MyClass.java
  java -Djava.compiler="" MyClass

Third-Party Tools

Some of the other tools available include those that reduce the size of the generated Java class files. The Java class file contains an area called a constant pool. The constant pool keeps a list of strings and other information for the class file in one place for reference. One of the pieces of information available in the constant pool are the method and field name.

The class file refers to a field in the class as a reference to an entry in the constant pool. This means that as long as the references stay the same, it does not matter what the values stored in the constant pool are. This knowledge is exploited by several tools that rewrite the names of the field and methods in the constant pool into shortened names. This technique can reduce the class file by a significant percentage with the benefit that a smaller class file means a shorter network download.

[TOP]