Java

README

Java HotSpotTM Server VM

Version 2.0 for Win32 Platforms

      

Contents

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

Introduction

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:

Please report bugs found in this release using the bug-report form at http://java.sun.com/cgi-bin/bugreport.cgi.

Changes in Version 2.0

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.

System Requirements

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.html

To download the Java 2 SDK v1.3:
http://java.sun.com/j2se/1.3/download-windows.html

The 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.

Installing the Java HotSpot Server VM

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.

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:

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.

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:

jvm.dll
The Server VM's library file.

Xusage.txt
Usage messages for command-line flags.
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.

After installing the Java HotSpot Server VM, verify that it is installed correctly by running this command:

java -version
If the Java HotSpot Server VM is installed correctly, you will see this line in the version output:
Java HotSpot(TM) Server VM (2.0-E, mixed mode)
If this is not the output you see, check the troubleshooting section below.

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:

Java HotSpot(TM) Server VM (2.0-E, mixed mode)
If your output doesn't contain this line, the cause may be one of the following.

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.

Using the Java HotSpot Server VM

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.html

On 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 -version

If 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.

JNI and the Java HotSpot Server VM

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 JVMDI Implementation

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.

Limitations

This release of the Java HotSpot Server VM has the following limitations:


Copyright © 1999, 2000 Sun Microsystems, Inc. All Rights Reserved. Sun