Java(TM) Virtual Machines JavaTM Virtual Machines Documentation Contents 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. Enhancements in J2SE 1.4.1: 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 machines. 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. Enhancements in J2SE 1.4.0: Signal chaining Error-reporting 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 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, 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 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. Command-Line Options 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. See Also The following additional documentation is available on the Sun web site. Performance Documentation FAQ for Java HotSpot Technology Java HotSpot VM Options Java HotSpot Architecture white paper The Java HotSpot Server VM: The Solution for Reliable, Secure Performance for the Enterprise Copyright © 2002 Sun Microsystems, Inc. All Rights Reserved. Please send comments to: j2se-comments@eng.sun.com
