Java^TM Virtual Machines

The Java 2 SDK, Standard Edition, contains two implementations of the Java virtual machine (VM).
Java HotSpot Client VM

The Java HoSpot 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 memory footprint.

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.

Signal chaining
Error-handling mechanism
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 supported.

The Solaris^TM-SPARC^TM 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, respectively.

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 J2SE 1.4.0 platform accepts class file versions in the range 45.3 to 48.0.

JavaTM Virtual Machines

New Features and Changes

See Also

Java^TM Virtual Machines