The Fast Virtual Machine (Fast VM) is the hp® next-generation, Just-In-Time
(JIT) compiler designed to increase Java application performance.
By generating native code for methods as they are invoked, Fast VM yields application
performance at rates typically 4 to 5 times faster than the same application
run with the conventional Java Development Kit's (JDK) Classic JVM combined
with other JIT compilers.
This Fast VM release targets the Alpha microprocessor running
on hp Tru64 UNIX® systems.
This document highlights the Fast VM's benefits, describes its high performance
capabilities, and presents a detailed view into the Fast VM architecture and
Benefits of the Fast VM
Tru64 UNIX customers have come to rely on hp's timely SDK releases containing
the Classic JVM and JIT compiler. Now, with Fast VM, Tru64 UNIX users will enjoy
enhanced product features including:
- High Performance. Efficient object format and allocation,
runtime optimizations, and a Java execution environment highly tuned for the
Alpha platform take the runtime performance of Java applications to the next
level, virtually eliminating performance as a roadblock to deploying Java
- Java Compatibility. The Fast VM implements the full JDK
and passes all the Java Compatibility Kit (JCK) tests. This is in contrast
to research projects that have demonstrated excellent Java performance but
implement only a subset of the JDK.
- JDK Class File and Shared Library Support. Rather than
using its own modified versions, Fast VM takes advantage of the thoroughly
tested JDK class files and shared libraries.
- Ease of Use. Users are presented with a single integrated
java command. Fast VM is invoked by typing, "java -fast".
HIGH PERFORMANCE CAPABILITIES
Fast VM performance enhancements include direct execution of Java methods,
efficient object format and allocation, a Java execution environment highly
tuned for the Alpha architecture, and runtime optimizations. These techniques
were designed to make compilation time negligible to the Java user.
- Direct Execution
When the Classic JVM executes a Java program, it reads and then interprets
the bytecodes. The result is a JVM easily ported to numerous architectures
but with slow execution when compared to conventional programming languages.
A technique used to address the poor performance of Java bytecode interpretation
is the integration of a JIT compiler with the interpreter. Instead of interpreting
the bytecodes, the JVM passes them to the JIT compiler, which translates
them into native code for the platform on which it is running. Although
JIT compilers significantly increase performance, they are constrained by
the interpreter. For example, method invocation returns control back to
the interpreter to perform stack management rather than calling the method
Fast VM takes the approach of a conventional compiler and translates Java
bytecodes directly into native machine code. Thus, every Java method is
compiled. Java code executes as if it were written in a conventional programming
language: there is a single stack per thread and calls are direct and conform
to the Alpha calling standard. To the operating system, a Java method appears
just like a procedure written in a conventional programming language.
- Efficient Object Format
The Fast VM eliminates the performance bottleneck resulting from the Classic
JVM's representation of objects via handles.
Over the past decade, modern reduced instruction set computer (RISC) systems
have become prevalent. The speeds of these processors have increased at
much faster rates than corresponding memory systems. For many applications,
memory references rather than execution speeds become the performance bottleneck.
The Classic JVM represents an object as a pointer to a data structure called
a handle, which contains a pointer to the instance data.
This object layout results in an unnecessary memory reference for every
object access. Although handles have a number of desirable qualities (especially
related to garbage collection and portability), the additional memory reference
may result in significantly degraded performance on modern RISC processors.
A complication faced by Fast VM is that some native methods in the JDK
assume that an object reference points to a handle. The Fast VM provides
an innovative solution to this problem by allowing this infrequent case
of native methods accessing an object instance through a handle to work
while Fast VM accesses that same object instance with only a single level
of indirection. This is accomplished by allocating the handle and instance
data adjacent to each other. Instance data is accessed by adding an offset
to an object's address or by double indirection through the handle. Following
is an illustration of the Fast VM's object format:
The Fast VM Object Format
||[Handle] Pointer to Instance Data.
Contains the address of the 4th word of this structure.
||[Handle] Pointer to Sun Metadata
||Pointer to class object and garbage
||Monitor and Array Length Information
(actual data) [Instance Data]
- Fast Object Allocation
Tru64 UNIX provides an efficient implementation of native threads and quick
access to thread local storage, which allows Fast VM to perform fast object
allocation. Each thread is given its own memory area from which to allocate
objects. In the normal case, object allocation is accomplished by incrementing
a pointer and requires no synchronization with other threads.
- Fast Monitors
An attraction of the Java programming language is that it makes it easy
for programmers to write multi-threaded applications. In order to ensure
the consistency of a set of related data structures, synchronization primitives
are available to the programmer. These primitives are also used extensively
by the JDK libraries so that these libraries can be safely invoked by multi-threaded
In the common case that only one thread tries to lock a given object, synchronization
is accomplished without operating system intervention. The thread obtains
a spin lock located in the object header, updates the header, and releases
the spin lock. This results in monitor synchronization that is not a performance
bottleneck for most real world applications.
- Optimization of Runtime Checks
One of the appeals the Java programming language holds for programmers
is that it is strongly typed and provides automatic array bounds checking.
Fast VM performs extensive analysis to minimize any performance penalty
resulting from these runtime checks. For example, many array bound checks
are redundant and can be eliminated. If an array bounds check is required,
Fast VM performs a highly optimized code sequence that checks the lower
and upper bounds with a single comparison instruction.
Fast VM emits no additional instructions to detect a NULL pointer exception.
Instead, optimized code is emitted and if the infrequent incident of de-referencing
of a NULL pointer occurs, a signal is raised by the operating system, caught
by Fast VM, and translated into a NullPointerException exception. Thus,
only programs that actually de-reference NULL pointers run slower due to
this safety feature.
- Optimized Method Calls
The Fast VM monitors program execution and optimizes method calls based
on the changing environment. A key benefit of this approach is that users
avoid performance penalties due to features they are not using.
For example, if a method is not overridden, the method is called directly.
However, when the method is overridden, the direct call is replaced by a
call using a virtual function table (this action involves an extra memory
- Runtime Machine Specific Optimizations
An advantage that virtual machines have over conventional compilers involves
their knowledge of the runtime execution environment. For example, only
later versions of the Alpha processors have byte manipulation instructions.
Fast VM recognizes the type of Alpha processor it is executing on and emits
processor specific code patterns.
The Fast VM is written in a portable subset of C++ using high level object-oriented
abstractions and consists of reusable components. The following illustration
provides an overview of the Fast VM architecture:
Fast VM Executable
RTL Entry Points - called
directly from generated code
Java Native Interface
Native methods overriding
JDK provided versions
interpreter routines called by native methods
Compiler and Symbol Table
Architecture Command Processor
The Fast VM begins execution when the user invokes the java
command with the appropriate switch or environment variable set. The Command
Processor performs the following actions:
- Parses and interprets the specified switches and environment variables.
One of the command options is the name of the class containing the "main"
method to be executed.
- Loads the specified class resulting in the following:
- Allocation of the class's static variables.
- Production of stub code for each method of the class. Invoking the stub
code results in the method being compiled and executed. Additionally,
future invocations of the method go directly to the compiled code.
- Compilation and execution of the class's static initializer.
- Invokes the class's "main" method.
- Returns control to the user after the main method completes.
Architecture Runtime Subsystem
The most common method for returning control to Fast VM is through the RTL
Entry points. These consist of approximately 25 entry points that the
compiled code invokes directly. The entry points include:
- Mathematical routines for integer divide, integer remainder, floating point
divide, floating pointer remainder, or conversion.
- Object creation routines.
- Monitoring routines (enter and exit).
- Checking routines for array store and cast operations.
- Exception handling routine for throwing or catching exceptions.
- Compilation routines for compiling methods into native machine code.
Another way control is returned to the Fast VM occurs when the user invokes
a C or C++ routine that uses the Java Native Interface (JNI).
JNI provides the Java programmer a JVM-independent mechanism for writing native
methods. The function prototypes are provided in a file called "jni.h"
and the JVM provides the implementation of these functions. JNI routines perform
functions such as reading and writing a field, invoking a method, etc.
Rather than add expensive checks to generated code, Fast VM establishes exception
handlers to catch certain conditions. For example, instead of prefixing every
pointer dereference with a check for a NULL pointer, Fast VM emits code without
checks and establishes a signal handler which throws a NullPointerException
after the program dereferences address zero.
Both the Classic and Fast VMs use most JDK native methods. However, certain
native methods depend upon the Classic JVM's object layout. In these cases,
Fast VM provides an alternative implementation of the native method. The alternative
native methods are collected in the Native Methods subsystem.
One example is the java_lang_Object_hashCode which, when given
an object, returns its hashcode. The Classic JVM's implementation depends on
references that are pointers to immovable handles. In contrast, the Fast VM
eliminates handles and references are pointers to objects freely moved by the
Some of the native methods in the JDK reference static variables or call routines
exported by the Classic interpreter. In order to use these native methods, Fast
VM provides an implementation of the required interpreter entry points and collects
them together in the Glue subsystem. An example is a routine
called SignalError that is frequently called by native methods
implementing the Abstract Windowing Toolkit (AWT).
Architecture Reusable components
The Object Factoryis the heart of the JVM. It contains C++
classes responsible for creating and manipulating objects. For example, the
class JavaObject exports methods such as Create, MonitorEnter, and MonitorExit
that operate on instances of java.lang.Object. The architecture is such that
changing the format of an object involves modifying this one class. This class
is "extended" to provided specific subclasses such as JavaClassObject
(instances of java.lang.Class) and JavaArrayObject (array objects).
Operating System Services
The Operating System Services module contains routines providing
portable system services. Examples of these services include thread management,
exception processing, and file system operations.
Compiler and Symbol Table
The Compiler and Symbol Table module is responsible for loading
and verifying classes, compiling methods and providing access to the symbol
An integral part of the Fast VM is the Garbage Collector,
described in the next section.
Two common garbage collection algorithms are termed mark-and-sweep and copying.
The Fast VM garbage collector combines techniques of the conservative mark-and-sweep
and the accurate copying collectors.
A mark-and-sweep collection typically consists of
two phases. In the first phase, each object known to be reachable is visited
and marked as live and then scanned for references
to other objects, which in turn are visited. During the second phase, memory
is linearly traversed, or swept, and unmarked objects
are added to a free list. An optional third phase involves the compaction of
A copying collector divides memory into two areas,
referred to as
Objects are allocated in
fromspace. When this
area runs out, live objects are copied into
tospace area is then re-designated as
and the area formerly occupied by
tospace. Empirical studies show
that most Java objects are short lived and consequently a large percentage of
fromspace is not copied.
One key piece of data required by a copying collector
is precise information that determines whether a given memory location contains
a reference to an object. If the referenced object is copied, the memory location
must be updated with the new address. Because the Fast VM supports the JDK,
it must also support the old Native Method Interface (NMI). Therefore, when
a program is executing a native method that is accessed via NMI instead of the
newer JNI interface, the collector can not distinguish between an integer whose
value is coincidentally an address within the heap and an actual reference to
an object within that same heap. The collector has precise information regarding
references within Java frames, within objects, and within JNI native methods.
Mostly-Copying is effectively a hybrid conservative
and copying collector. It copies objects known to be alive and only pointed
to by precise references. Objects, that are referenced via imprecise pointers,
are not physically moved, but rather added to tospace using a sophisticated
bookkeeping algorithm. It is worth noting that at a given collection point only
a small percentage of the objects are referenced by imprecise pointers and typically
at the next collection point a different set objects is identified as being
imprecise. Another way of looking at this is that at a given collection point
only a small number of threads are likely to be in a non-JNI native method and
at the next collection point that native method has probably completed.
The Fast VM provides users of hp Tru64 UNIX with one of the fastest Virtual
Machines available today. This paper describes the architectural overview of
a modern JVM and emphasizes how hp customers benefit from Fast VM and its high
HP and the names of hp products referenced herein are either trademarks and/or
service marks or registered trademarks and/or service marks of hp.
UNIX is a registered trademark in the United States and other countries, licensed
exclusively through The Open Company.