READMEJava HotSpotTM Server VMVersion 2.0 for Win32 Platforms |
Introduction
Changes in Version 2.0
System Requirements
Installing the Java HotSpot Server VM
Using the Java HotSpot Server VM
JNI and the Java HotSpot Server VM
The Java HotSpot JVMDI Implementation
Limitations
The Java HotSpotTM Server VM is an add-on performance module for the JavaTM 2 SDK. The Java HotSpot Server VM employs state-of-the-art technology to offer many performance enhancements:For more information about the Java HotSpot Server VM, see the following documentation on the Sun web site:
- Adaptive compiler - The Java HotSpot Server VM launches an application using a standard interpreter, but then analyzes the code as it runs to detect performance bottlenecks, or "hot spots". It compiles 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 Server VM also uses the 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.
- Improved garbage collection - The Java HotSpot Server VM automatically reclaims ("garbage collects") objects that are no longer needed. The Java HotSpot Server VM includes a state-of-the-art garbage collector that is faster and more efficient than the garbage collector of the Java 2 SDK's Classic VM. As an option, the new garbage collector can operate in an "incremental" mode which eliminates virtually all the program-execution pauses that are typical of current garbage collectors.
- Thread synchronization - The Java programming language allows for use of multiple, concurrent paths of program execution (called "threads"). The Java HotSpot Server VM provides a leaner, speedier thread-handling capability that is designed to scale readily for use in large, shared-memory multiprocessor servers.
Please report bugs found in this release using the bug-report form at http://java.sun.com/cgi-bin/bugreport.cgi.
Beginning with version 2.0, the product name has been changed from Java HotSpot Performance Engine to Java HotSpot Server VM. This change was made to emphasize that the Java HotSpot Server VM is intended for use in the enterprise server environment, and to distinguish it from the Java HotSpot Client VM that will ship as part of version 1.3 of the Java 2 SDK.The principal enhancement of version 2.0 of the Java HotSpot Server VM over version 1.0 is the increase in bytecode execution speed. Performance tuning of the Java HotSpot dynamic compiler has made version 2.0 30% faster than version 1.0 on standard benchmarks.
The default size of the initial memory allocation pool (the heap) has been reduced to 2 MB. The default maximum heap size is 64 MB as in version 1.0.1. Most servers have more memory than that available, and it's recommended that the initial and maximum heap sizes should be adjusted upwards to more closely match the actual memory available for the virtual machine on the server. These heap-size parameters may be adjusted by using the -Xms and -Xmx command-line options of the Java application launcher.
This release of the Java HotSpot Server VM can be used with either version 1.2.2 or 1.3 of the Java 2 SDK or Java 2 Runtime Environment. You can download these from the Java Software web site.To download the Java 2 SDK v1.2.2:
http://java.sun.com/products/jdk/1.2/download-windows.htmlTo download the Java 2 SDK v1.3:
http://java.sun.com/j2se/1.3/download-windows.htmlThe recommended platform for using the Java HotSpot Server VM is the same as that recommended for the Java 2 SDK. You should have a PC with at least 48 megabytes of RAM, running Windows NT 4.0 or Windows 2000 Professional. On Windows NT, the Java HotSpot Server VM has been tested with Service Pack 4, and Service Pack 5. It has not been tested on Windows NT 3.51.
Machines having less than 48 MB of RAM may experience a large amount of disk swapping when running applications and benchmark programs that use all, or nearly all, of the 64 MB of the memory allocation pool. The default size of the memory allocation pool can be adjusted by using the -Xmx option of the Java application launcher.
The Java HotSpot Server VM is intended for use in server environments. However, it has been thoroughly tested on Windows 95 and Windows 98.
The Java HotSpot Server VM is designed for easy, plug-in installation in the Java 2 SDK and Java 2 Runtime Environment. It comes bundled as an executable InstallShield wizard in a file called hotspot2_0-win.exe.You can install the Java HotSpot Server VM in any of the following:
The Java HotSpot Server VM's installer will check the registry during installation to determine which of these is installed. The installer must find at least one of these installed or it will abort the installation.
- Java 2 SDK, v1.3
- Java 2 Runtime Environment v1.3
- Java 2 SDK, v1.2.2
- Java 2 Runtime Environment, v1.2.2
Choosing the Default VM
If you are installing the Java HotSpot Server VM on a 1.3 Java 2 Platform, the installer will ask you to select which VM implementation you would like to be the default. Your choices will be:
- Java HotSpot Server VM -- This is the VM implementation you just installed. Select this VM as the default if you will be running primarily server applications for which peak operating speed is more important than start-up time.
- Java HotSpot Client VM -- This is the VM implementation that ships as part of the Java 2 SDK and Java 2 Runtime Environment v 1.3. Choose this VM as the default if you will be running primarily client applications for which start-up time is as important as peak operating speed.
You can change the default VM at any time after installation by running the set_default_VM.exe utility. This utility is installed along with the Server VM in the jre\bin\server directory in the Java 2 SDK, or in the bin\server directory inside the Java 2 Runtime Environment. Launch the utility by double clicking its icon, and it will guide you through the process of changing the default VM.
Regardless of which VM is set as the default, you can select either VM on the command-line by using the following options. These options must appear before any other options in the command.
- -server: invokes the Java HotSpot Server VM.
- -hotspot: invokes the Java HotSpot Client VM.
- -classic: invokes the Java 2 Classic VM (not available on version 1.3 of the Java 2 Runtime Environment).
If you installed the Java HotSpot Server VM on version 1.2.2 of the Java 2 Platform, it is automatically the default VM. You can invoke the Java 2 Classic VM instead by using the -classic command-line option.
Double click on the hotspot2_0-win.exe file's icon to launch the installation program. You will be prompted to agree with the terms of the license agreement, and you will be given the choice of installing the Java HotSpot Server VM either in the Java 2 SDK or in the Java 2 Runtime Environment. The installer will determine if either version 1.2.2 or 1.3 of the Java 2 SDK or Java 2 Runtime Environment is installed, and will prompt you to confirm the version into which you want to install the Server VM. If the installer doesn't detect that either 1.2.2 or 1.3 is already installed, it will abort the Server VM installation.
The Java HotSpot Server VM consists of two files:
In addition, a proprietary rights notice is installed as the file PRNotice. A set_default_VM.exe is also installed for use in changing the default VM, if desired, after installation. The installer places these files in the jre\bin\server directory of the Java 2 SDK or Java 2 Runtime Environment.
jvm.dll
- The Server VM's library file.
Xusage.txt
- Usage messages for command-line flags.
After installing the Java HotSpot Server VM, verify that it is installed correctly by running this command:
If the Java HotSpot Server VM is installed correctly, you will see this line in the version output:java -versionIf this is not the output you see, check the troubleshooting section below.Java HotSpot(TM) Server VM (2.0-E, mixed mode)Troubleshooting the Installation
This section discusses troubleshooting under the assumption that the Java HotSpot Server VM is installed on top of version 1.3 of the Java 2 platform. The troubleshooting tips apply equally well, however, to version 1.2.2 of the Java 2 platform.If the Java HotSpot Server VM is properly installed, running the 'java -version' command should produce output containing this line:
If your output doesn't contain this line, the cause may be one of the following.Java HotSpot(TM) Server VM (2.0-E, mixed mode)
- The Java HotSpot Server VM is not installed in the correct location. Check to ensure that the two files of the Java HotSpot Server VM are installed in the SDK's jre\bin\server directory. If you have also installed the VM in the Runtime Environment, it should be in the bin\server directory of the Runtime Environment which is typically located in the C:\Program Files\JavaSoft\JRE\1.3 directory.
- You are using the wrong java.exe application launcher. When both the Java 2 SDK and Java 2 Runtime Environment are installed in your system, copies of the java.exe file (the Java application launcher) wind up in four locations, as indicated in the following table.
Java.exe location Runtime libraries used In the SDK at jdk1.3\bin\java.exe This copy of java.exe uses the libraries in the SDK. In the SDK at jdk1.3\jre\bin\java.exe This copy of java.exe uses the libraries in the SDK. In the Runtime Environment at
C:\Program Files\JavaSoft\JRE\1.3\bin\java.exeThis copy of java.exe uses the libraries in the Runtime Environment. On the system path at
C:\winnt\system32\java.exe (WinNT) or
C:\windows\system\java.exe (Win95 & Win98)This copy of java.exe uses libraries in the Runtime Environment. Notice that two of the copies of the java.exe application launcher use the libraries in the Java 2 Runtime Environment rather than those of the Java 2 SDK. Therefore, if you are running one of these copies of the application launcher, the Java HotSpot Server VM won't be invoked unless it is installed in the Runtime Environment.
Note - If you use the Invocation API to launch an application directly rather than using the Java.exe application launcher, be sure to invoke the Java HotSpot Server VM at jre\bin\server\jvm.dll rather than the classic VM at jre\bin\classic\jvm.dll.The Java HotSpot Server VM will not work with any version of the JDKTM 1.1.x or JRE 1.1.x software, or earlier versions.
After the Java HotSpot Server VM is installed in the Java 2 SDK and has been chosen as the default VM, an application can be run by simply launching it in the usual way:java MyApp appletviewer MyApplet.htmlOn 1.3, the -server and -hotspot command-line options can be used to select a VM implementation for use regardless of which implementation is set as the default.
You can use the -version flag to determine whether or not the Java HotSpot Server VM is being used:
java -version java -classic -versionIf you notice that your code behaves differently when using the Java HotSpot Server VM as compared with the classic VM, the cause may be the classic VM's method dispatch bug described in Method Dispatch Differences.
The default values of the initial and maximum heap size, 2 MB and 64 MB respectively, are too small for most servers. It is recommended that these values should be adjusted upwards to more closely match the actual memory available for the virtual machine on the server. These heap-size parameters may be adjusted by using the -Xms and -Xmx command-line options of the Java application launcher.By default, the Java HotSpot Server VM operates in "mixed mode". This means that heavily used program segments (hot spots) are compiled to native code, and the remaining bytecodes are executed by a bytecode interpreter. This mode provides the fullest performance benefit offered by the Java HotSpot Server VM.
Documentation for the Java application launcher (the java.exe utility) is available in the Java 2 SDK documentation. The Java application launcher's web page describes both "standard" launcher options and "non-standard" options. The Java HotSpot Server VM supports all standard options and also has its own set of non-standard options that are different from the non-standard options of the classic VM. The non-standard options of the Java HotSpot Server VM are:
-Xint
- Operate in interpreted-only mode. Compilation to native code is disabled, and all bytecodes are executed by the interpreter. The performance benefits offered by the Java HotSpot Server VM's adaptive compiler will not be present in this mode.
-Xbatch
- Disable background compilation. Normally, if compilation of a method is taking a long time, the VM will compile the method as a background task, running the method in interpreter mode until the background compilation is finished. The -Xbatch flag disables background compilation so that compilation of all methods proceeds as a foreground task until completed, regardless of how long the compilation takes. This flag is provided for users who desire more deterministic behavior of method compilation for purposes such as benchmarking.
-Xincgc
- Enable the incremental garbage collector. The incremental garbage collector, which is off by default, will eliminate occasional garbage-collection pauses during program execution. However, it can lead to a roughly 10% decrease in overall GC performance.
-Xms<size>
- Specify the initial size, in bytes, of the memory allocation pool. This value must be a multiple of 1024 greater than 1MB. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. The default value is 2MB. Examples:
-Xms6291456 -Xms6144k -Xms6m-Xmx<size>
- Specify the maximum size, in bytes, of the memory allocation pool. This value must be a multiple of 1024 greater than 2MB. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. The default value is 64MB. Examples:
-Xmx83886080 -Xmx81920k -Xmx80m- -XX:NewSize=<size>
- Specify the initial size, in bytes, of the young object space where new objects are allocated. The default initial young space size is 2MB. NewSize must be a multiple of 1024. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. Example:
- -XX:NewSize=4096k
- sets the initial size of the young space to 4MB. Note that a large young space size may result in increased garbage collection pause times.
- -XX:MaxNewSize=<size>
- Specify the maximum size, in bytes, of the young object space where new objects are allocated. The initial young space size is 2MB. MaxNewSize must be a multiple of 1024, and greater than 2MB. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. The default value for MaxNewSize is 64MB. Example:
-XX:MaxNewSize=4096k- -XX:NewSizeThreadIncrease=<sizeInKb>
- As more threads are created in a server application, the object allocation rate may increase with the number of active threads. The number of active threads is considered when adjusting the size of the young space, after a garbage collection. This flag specifies, in Kilobytes, the increment in young object space size, per active thread, to accomodate potentially faster object allocation rate. The default increment is 16Kb. For example:
-XX:NewSizeThreadIncrease=32-Xbootclasspath:<bootclasspath>
- Specify a semicolon-separated list of directories, JAR archives, and ZIP archives to search for boot class files. These will be used in place of the default boot class files in the jre/lib/rt.jar and jre/lib/i18n.jar archives normally used by the Java 2 software.
-Xfuture
- Perform strict class-file format checks. For purposes of backwards compatibility, the default format checks performed by the Java 2 SDK's virtual machine are no stricter than the checks performed by 1.1.x versions of the JDK software. The
-Xfuture
flag turns on stricter class-file format checks that enforce closer conformance to the class-file format specification. Developers are encouraged to use this flag when developing new code because the stricter checks will become the default in future releases of the Java application launcher.-Xprof
- Profiles the running program, and sends profiling data to standard output. This option is provided as a utility that is useful in program development and is not intended to be be used in production systems.
-Xnoclassgc
- Disables garbage collection of classes.
-X
- Prints out a brief usage message describing the non-standard options.
When using the Java HotSpot Server VM with JNI, be sure to pair each Get<primitive type>ArrayElements function call with the corresponding Release<primitive type>ArrayElements call. Failure to do so can result in memory leaks. Because of the way the classic VM implements conservative garbage collection, unpaired Get<primitive type>ArrayElements calls do not result in memory leaks when using the classic VM.The Java HotSpot Server VM will not work with any version of JNI other than that which ships as part of the Java 2 Platform v 1.2.2 or 1.3
The Java HotSpot Server VM contains an implementation of the Java Virtual Machine Debug Interface (JVMDI). Debugging tools that are designed to interface with JVMDI can be used in conjunction with the Java HotSpot Server VM. One such debugging tool is the new jdb debugger utility that ships as part of the Java Platform Debugger Architecture (JPDA) in Java 2 SDK v1.3. The jdb utility that ships as part of the Java 2 SDK v1.2.2 makes use of old native-code interfaces that are not supported by the Java HotSpot Server VM.
This release of the Java HotSpot Server VM has the following limitations:
- The Java HotSpot Server VM will not work with any version of JNI other than that which ships as part of the Java 2 Platform v 1.2.2 or 1.3 The Java HotSpot Server VM does not and will not support native method conventions older than JNI.
- A bug in JMF1.1 prevents JMF from playing .mov (QuickTime) files when run on the Java HotSpot Server VM.
- Machines having less than 48 MB of RAM may experience a large amount of disk swapping when running applications and benchmark programs that use all, or nearly all, of the 64 MB of the memory allocation pool. The default size of the memory allocation pool can be adjusted by using the -Xmx option of the Java application launcher.
Copyright © 1999, 2000 Sun Microsystems, Inc. All Rights Reserved. |