HPlogo Communicator e3000 MPE/iX Express 1 Based on Release 7.0 > Chapter 5 Technical Articles

Introducing the HotSpot Virtual Machine for Java

MPE documents

Complete PDF
Table of Contents
Index

by Mike Yawn, Commercial Systems Division

The implementation of Java on the HP e3000 just got a lot faster thanks to the new technology included in the HotSpot Virtual Machine. The HotSpot VM is a completely compatible alternative to the Classic Java Virtual Machine. The latest Software Developer's Kit (SDK) for Java, which is included with this release, contains both the HotSpot and the Classic JVMs

What's new?

The primary advantage of the HotSpot VM is performance. Benchmarks show typical performance improvements of from 2 to 5 times when using the HotSpot VM compared to the 'Classic' virtual machine shipped in all versions of Java to date.

HotSpot VM Features

  • Performance

Faster interpreter than the Classic Java VM
HotSpot compiler is more selective about what code to compile, and then compiles selected code to higher levels of optimization than JIT compilers
Better garbage collection and thread synchronization performance

  • Better scaleability on multiprocessor systems

  • Improved reliability

  • Platform for future performance improvements

What's included

The HotSpot and Classic JVMs both co-exist in this release of Java. In a future release, the Classic JVM will be dropped and HotSpot will be the only JVM provided. There were changes made to the Java directory structure beginning in JDK 1.2 in order to support the eventual release of HotSpot.

Java is installed in a directory location beginning with 

    /usr/local/java/jdk1.3
The portions of Java that change with hotspot are two libraries, libjvm (the Java VM) and libhpi (the Host Porting Interface). The Classic versions of these files are in the following locations: 

    /usr/local/java/jdk1.3/jre/lib/PA-RISC/classic/libjvm.sl
    /usr/local/java/jdk1.3/jre/lib/PA-RISC/green_threads/libhpi.sl
The HotSpot versions of the same two files are located here: 

    /usr/local/java/jdk1.3/jre/lib/PA-RISC/hotspot/libjvm.sl
    /usr/local/java/jdk1.3/jre/lib/PA-RISC/native_threads/libhpi.sl
The HotSpot versions of the same two files are located here: 

    /usr/local/java/jdk1.3/jre/lib/jvm.cfg
With MPE/iX 7.0 Express 1, the Java SDK included is configured with classic as the default JVM. At some future release, probably based on SDK 1.3.1, we will change the default JVM to be the HotSpot JVM. Later still, probably in a release based on SDK 1.4, the Classic JVM will be dropped from the Java distribution. Customers are encouraged to test all of their Java software using the HotSpot JVM at the earliest opportunity, so that any compatibility problems can be identified and fixed before the discontinuance of the Classic JVM.

How to use the HotSpot JVM

As mentioned above, the jvm.cfg file determines whether the Classic or HotSpot JVM will be the default JVM for your system. You can also request a specific JVM on a case-by-case basis by using the appropriate command line switch, for example: 
  java -hotspot HelloWorld  # selects the HotSpot JVM
  java -classic HelloWorld  # selects the Classic JVM
If a VM option is specified, it must be the first argument on the command line. If no VM option is specifed, the default VM (as configured in jvm.cfg) will be used.

There are a few additional files that will be referenced by the HotSpot VM if they are present. When you invoke HotSpot, if there is a file named .hotspotrc in your current working directory, this file will be read. This file can contain various switches to be passed to the HotSpot Virtual Machine. For example, here is a possible .hotspotrc file: 

  # Sample .hotspotrc.  Lines beginning with # are comments
  +ServerApp
  +PrintGC
  MaxHeapSize=64000
The first two switches are boolean flags, which can be turned on by a leading +, or off by a leading -. +ServerApp causes the VM to inline more aggressively, which uses more memory, may slow down compilations and may make smaller apps run slower, but which can provide a performance benefit for larger, longer running applications. The second flag is equivalent to the -verbose:gc switch on the Classic VM (and -verbose:gc can still be specified on HotSpot as an alternative to this new syntax). The third flag is an integer flag, which specifies a value (the size of the VM heap, in Kbytes). The exact set of flags available is still undergoing change at the time this article is written, and may evolve over the course of the next several releases. For this reason, you should not rely on the presence or behavior of any particular VM flags at this point.

As an alternative to using the .hotspotrc file, you can also set these flags directly on the command line by using a -XX: prefix, for example, -XX:+ServerApp would turn on the ServerApp flag. Finally, you can use an alternate file rather than .hotspotrc, and specify your alternate file by passing -XX:Flags=filename on the java command line.

Another file that will be read at startup time is the .hotspot_compiler file. This file is typically used to exclude certain code from being compiled by the HotSpot compiler. The format of the file is: 

    exclude classname methodname

  for example,

    exclude java/util/HashTable rehash
HotSpot will write entries to this file if it encounters a method it is unable to compile, so that future invocations of the compiler won't reattempt the compilation. You can manually add entries to the file as well, if for some reason you wish to exclude a particular method from compilation. If you want to turn off compilation altogether, use the -Xint switch the the JVM, which runs HotSpot in interpreted mode. This is roughly equivalent to the -Xnojit switch of the Classic JVM.



Pascal/iX has $VOLATILE_WITH Option Enhancement

Chapter 6 Technical Articles