The Java 2 SDK, Standard Edition, contains two implementations of the
Java virtual machine (VM).
Java HotSpot Client VM
The Java HotSpot Client VM is the default virtual machine of
the Java 2 SDK and Java 2 Runtime Environment. As its name implies,
it is tuned for best performance when running applications in a
client environment by reducing application start-up time and
Java HotSpot Server VM
The Java HotSpot Server VM is designed for maximum program
execution speed for applications running in a server environment.
The Java HotSpot Server VM is invoked by using the -server
command-line option when launching an application, as in
java -server MyApp
Some features of Java HotSpot technology, common to both VM implementations,
are the following.
Adaptive compiler - Applications are launched using a
standard interpreter, but the code is then analyzed
as it runs to detect performance bottlenecks, or "hot spots".
The Java HotSpot VMs compile those performance-critical portions
of the code for a boost
in performance, while avoiding unnecessary compilation of seldom-used
code (most of the program). The Java HotSpot VMs also
usesthe adaptive compiler to decide, on the fly, how best to optimize
compiled code with techniques such as in-lining. The runtime analysis
performed by the compiler allows it to eliminate guesswork in determining
which optimizations will yield the largest performance benefit.
Rapid memory allocation and garbage collection -
Java HotSpot technology provides for rapid memory allocation for
objects, and it has a fast, efficient, state-of-the-art garbage collector.
Thread synchronization - The Java programming language
allows for use of multiple, concurrent paths of program execution
(called "threads"). Java HotSpot technology provides a
thread-handling capability that is designed to scale readily for use
in large, shared-memory multiprocessor servers.
New Features and Changes
The following are some of the recently added features in the
Java HotSpot VMs.
J2SE 1.4.1 is available in versions that support the 64-bit
Intel Itanium processor on Linux Red Hat 7.2
and Windows XP 64-bit edition. Look for the downloads for these
versions on the J2SE 1.4.1 download page.
In this release, these 64-bit versions have the following limitations.
Applications can be run only in interpreted mode. The platform
will run in interpreted mode by default, with no need to supply the
-Xint flag on the command line when launching an application.
When using the 64-bit versions of the J2SE 1.4.1 platform, the command
java MyApp will launch and execute MyApp by interpreting
the bytecode. Java HotSpot-technology-based dynamic compilers for
64-bit support is planned for a future release of the J2SE platform.
The 64-bit versions of J2SE 1.4.1 do not include the Java Plug-in
and Java Web Start products.
The 64-bit versions of J2SE 1.4.1 do not have an installer application.
These versions are available only as a tar bundle.
The 32-bit versions of the J2SE 1.4.1 will not work on Intel Itanium
A deadlock detection utility has been added to the Java HotSpot VM.
The utility is invoked by a Ctrl+\ on the command line while an
application is running. The utility detects Java-platform-level
deadlocks, including locking done from the Java Native Interface (JNI),
the Java Virtual Machine Profiler Interface (JVMPI), and Java Virtual Machine
Debug Interface (JVMDI).
When invoked, the utility displays a thread dump to standard out
and indicates any Java-platform-level deadlocks it detects. Refer
to this sample output.
If the application is deadlocked because two or more threads are
involved in a cylce to acquire monitors, then the list of such
threads and monitors involved in the deadlocks are displayed.
Note, however, that this will not find deadlocks involving
threads waiting on monitors on which no signal will be forthcoming.
The new -Xloggc:file option reports on each
garbage-collection event, as with -verbose:gc, but logs this
data to file. In addition to the information
-verbose:gc provides, each reported event is preceeded by the
time (in seconds) since the first garbage-collection event.
Beginning with J2SDK 1.4.0, the Classic Virtual Machine is no
longer shipped as part of the Java 2 SDK. (On Solaris platforms, the
Classic VM was removed in J2SDK 1.3.0.) If you have been running
your applications on the Classic VM by using the -classic
command-line option, you will need to use either the Java HotSpot
Client VM (invoked by default or by using the -client option)
or Java HotSpot Server VM (invoked with the -server
option). Attempting to launch an application with the -classic
option will result in this message: Error: Classic VM no longer
The SolarisTM-SPARCTM platform edition of J2SDK 1.4.0
will support 64-bit operation on 64-bit Sparc-v9
platforms when using the Java HotSpot Server VM. With
a 64-bit address space, more than four gigabytes of heap
memory is available. The Java HotSpot Server VM
includes support for both 32-bit and 64-bit operations,
and users can select either 32-bit or 64-bit operation by
using command-line flags -d32 or -d64,
Users of the Java Native
Interface will need to recompile their code to be able
to run it on the 64-bit VM.
There is no 64-bit support for the Java HotSpot
Client VM. Only the Java HotSpot Server VM provides for
optional 64-bit operation.
Users must install 64-bit Solaris support in order
to run the virtual machine in 64-bit mode.
On older Sparcv9 systems, users must modify the file
/platform/sun4u/boot.conf in order to enable
64-bit programs. See the text in the boot.conf
file for more information.
The new -Xcheck:jni command-line option performs
additional checks for Java Native Interface (JNI) functions.
Specifically, the Java Virtual Machine validates the parameters passed
to the JNI function as well as the runtime environment data before
processing the JNI request. Any invalid data encountered indicates a
problem in the native code, and the Java Virtual Machine will terminate
with a fatal error in such cases. Expect a performance degradation when
this option is used.
The J2SE 1.4.0 platform accepts class file versions in
the range 45.3 to 48.0.
Some operating characteristics of the Java HotSpot VM can be
controlled by the use of command-line flags.
The command-line options supported by the Java HotSpot VMs are
described on the reference pages for the Java application launcher
(Microsoft Windows | Solaris Operating Environment | Linux). Non-standard options recognized by the current
implementations of the VMs, but not necessarily by future or non-Sun
implementations, are described on the Java HotSpot VM Options web page.
The following additional documentation is available on the
Sun web site.