-XX:+AggressiveHeap
This option instructs the JVM to push memory use to the limit:
the overall heap is around 3850MB, the memory management policy defers
collection as long as possible, and (beginning with J2SE 1.3.1.05)
some GC activity is done in parallel. Because this option sets heap size,
do not use the -Xms or -Xmx options in conjunction with -XX:+AggressiveHeap.
Doing so will cause the options to override each other's settings for heap size.
Because the -XX:+AggressiveHeap option has specific system requirements
for correct operation and may require privileged access to system
configuration parameters, it should be used with caution.
We have found it to be useful for certain applications that create a lot of
short lived objects. Instructs the JVM not to complain if the application
installs signal handlers.
-XX:+DisableExplicitGC
Disable calls to System.gc(). The JVM still performs garbage collection
when necessary.
-XX:MaxNewSize=<size> (not supported on 1.3)
Sets the maximum size of new generation (in bytes). Note that in
HotSpot 1.0.1 this option took an integer that specified a value in
Kbytes. Starting with HotSpot 1.3.1, the integer argument specifies
bytes. The arguments can now be followed by either 'k' or 'm' to
specify Kbytes or Mbytes.
-XX:NewSize=<size>
Sets the default size of new generation (in bytes). Note that in
HotSpot 1.0.1 this option took an integer that specified a value in
Kbytes. Starting with HotSpot 1.3.1, the integer argument specifies
bytes. The arguments can now be followed by either 'k' or 'm' to
specify Kbytes or Mbytes.
-XX:NewSizeThreadIncrease=<sizeInKb>
Sets the additional size added to desired new generation size per
non-daemon thread (in bytes). Note that in HotSpot 1.0.1 this option
took an integer that specified a value in Kbytes. Starting with HotSpot
1.3.1, the integer argument specifies bytes. The arguments can now be
followed by either 'k' or 'm' to specify Kbytes or Mbytes.
-XX:MaxPermSize
Sets the maximum size of permanent generation (in bytes). Note that in
HotSpot 1.0.1 this option took an integer that specified a value in
Kbytes. Starting with HotSpot 1.3.1, the integer argument specifies
bytes. The arguments can now be followed by either 'k' or 'm' to
specify Kbytes or Mbytes.
-XX:+ServerApp
A set of XX options which, when bundled together, make some applications
run faster. For each release, the options as well as the values may be
different depending upon the default values of XX options. We recommend
that you test to see whether this set enhances the performance of your
application before you use the option in production.
-XX:SurvivorRatio=<size>
Ratio of eden/survivor space size. Default for SDK 1.3 is 64MB. Number
can include 'm' or 'M' for megabytes, 'k' or 'K' for kilobytes, and
'g' or 'G' for gigabytes. For example, 32k is the same as 32768.
-XX:+UseCompilerSafepoints (PA-RISC 1.3.1, 1.4 and later, Itanium 1.4.2 and later)
Enables compiler safe points. In this release, compiler safe points
is off by default. Enabling compiler safepoints guarantees
a more deterministic delay to stop all running java threads before
doing a safepoint operation, namely garbage collection and deoptimization.
In this release, a patch is required. See "Known Problems" in these release
notes.
-XX:+UseOnStackReplacement (PA-RISC 1.3.1, 1.4 and later, Itanium 1.4.2 and later)
Enables on stack replacement. In this release, on stack replacement
is off by default. On stack replacement enables the interpreter
to go into compiled code while it is executing the same instance of the
method call. If you enable on stack replacement, you should also enable
compiler safe points (see the previous option). For this release, a patch
is required. See "Known Problems" in these release notes.
-XX:+UseSIGUSR2 (PA-RISC only)
Use the java command line option -XX:+UseSIGUSR2 if you want the JVM
to use SIGUSR2 for internal operations like Thread.interrupt() calls
instead of SIGUSR1, the default. This allows you to better implement
third party middleware applications that in some versions want to use
SIGUSR1 for similar purposes in their native code.
HP specific options and features
Additional HP specific documentation is provided in the HP-UX Programmer's Guide
Noteworthy HP specific options and features for Java 2 version
1.3 include the following:
-pa
-pa11 (PA-RISC only)
-Xeprof
-Xnocatch
-Xoptgc
-Xprep
-verbosegc
-Xverbosegc
and the FastSwing feature.
These are described below.
-pa option
If you have downloaded both the IPF and PA SDK on an IPF system, you can run
the PA SDK by specifying this option. Normally, Java detects that
you are executing on an IPF system and launches the IPF driver. To
launch the PA driver and use the PA2.0 libraries, use this option.
-pa11 option (PA-RISC only)
HP's PA-RISC 2.0 architecture offers performance features not compatible
with previous architectures. PA1.1 binaries can be run on a PA1.1
as well as PA2.0 based systems; however, a PA2.0 binary can only run
on a PA2.0 based system. Starting with the 1.2.2 release of the SDK,
HP includes two versions of the shared libraries comprising APIs and VMs.
The PA2.0 shared libraries will be default if the user is running on a
PA2.0 system. The user can override the use of the PA2.0 version of the
shared libraries on a PA2.0 by specifying the -pa11 flag. For example:
On a PA2.0 based system, invoking Java by typing
java -version
results in something similar to:
java version "1.3.1"
HotSpot VM (..., mixed mode, PA2.0 build 1.3.1.00-00/04/23-PA_RISC 2.0)
The generated version string indicates that the PA2.0 version of the
VM will be used.
You can override the use of the PA2.0 version of the VMs and APIs on a
PA2.0 system by adding the -pa11 flag as follows:
java -pa11 -version
This results in something similar to:
java version "1.3.1"
HotSpot VM (..., mixed mode, PA1.1 build 1.3.1.00-00/-4/23-PA_RISC 1.1)
The version string indicates that the PA1.1 version of the VM in spite of
the fact that we are running on a PA2.0 system.
Note: If you run HotSpot with the -pa11 flag or run on a PA 1.1 system, your
heap address space will be restricted to 1G.
-Xeprof option
The -Xeprof option generates profile data for HPjmeter. The -Xeprof option
enables profiling of Java applications running on HotSpot version 1.2.2.05 or
greater and collects method clock and CPU times, method call count, and call
graph. (For more information on HPjmeter, see HPjmeter Downloads and Documentation.)
To profile your application use the following command:
java -Xeprof:<options> ApplicationClassName
To profile your applet, use:
appletviewer -J-Xeprof:<options> URL>
where <options> is a list of <key>[=<value>] arguments
separated by commas.
After the profiled applet or application normally terminates execution,
the Java Virtual Machine writes the profile data to a file in the current
directory.
We have found the following options useful in most cases:
For CPU time metrics with minimal intrusion:
-Xeprof or
-Xeprof:ie=no
Exact call count information and object creation profiling:
-Xint -Xeprof:ie=no
To see the complete list of available options, use
java -Xeprof:help
Here are the supported -Xeprof options:
file=<filename>
The profile data will be written to the named file. The default
is java.eprof.
times=quick|thorough
Collect call graph with inclusive method clock and CPU times
and method call count.
This option uses tracing with reduction
and collects the data separately for each thread,
throughout the whole execution time of the program.
The quick value instructs the profiler to use
the hardware Interval Timer register for time measurement.
This value results in faster profiling runs, but in very rare
circumstances can produce inaccurate data.
This is the default for PA-RISC 2.0 based machines.
If you ever suspect that the profile data generated using the
quick value is incorrect then redo the run to see
whether the results can be replicated.
The thorough value is the opposite of quick, disabling the use of
the Interval Timer. The profiling runs will be longer, but will
provide timing data with the same quality as the system calls used to
measure the time. However, the profiling intrusion and overhead also
increase. This is the default for PA-RISC 1.1 based machines.
ie=yes|no
Enable/disable the profiling intrusion estimation.
ie=yes, the default value, specifies that the profiler
estimate the profiling intrusion
and write the estimated values to the profile data file.
A future version of HPjmeter will be able to present the timing data as:
raw, meaning the data as collected, or compensated, meaning with the
estimated intrusion subtracted.
Disabling intrusion estimation reduces the size of the data files,
but will also disable the intrusion compensation feature.
inlining=disable|enable
Disable/enable inlining in the HotSpot VM.
The compiler in the HotSpot VM optimizes Java applications by inlining
frequently called methods. Execution of inlined methods does not count as
"calls" from the profiler's viewpoint. Instead, the time spent in an
inlined method is attributed to its caller.
The count of created objects cannot be reliably estimated in the presence
of inlining, because the calls to the constructors may have been inlined.
To obtain an accurate method call count and to enable the created objects
metric, run the VM with inlining=disable.
-Xnocatch
The -Xnocatch option disables the Java "catch-all" signal handler.
Use this option to generate clean stack traces from native code.
-Xoptgc
The Xoptgc, or 'optimistic garbage collection' flag, improves garbage
collection performance of applications with mostly short-lived objects. A
server-side application that creates many short-lived objects for each
transaction is likely to benefit greatly with Xoptgc. However this flag should be
used with caution. It is not recommended for applications that build
up objects quickly during the run time that are not short-lived.
-Xprep
The -Xprep option is used to dynamically preprocess (modify) bytecodes
of the classes loaded by the VM. Its syntax is:
-Xprep <factory_class_name>:<arguments>
where <factory_class_name> is a qualified name of the class that will
be used to create the preprocessor, and <arguments> is any string that
will be passed to the method creating the preprocessor. The location
of the factory class must be specified in the -Xbootclasspath option
passed to the VM, together with the location of the appropriate rt.jar.
When the -Xprep option is specified, before loading the application
classes, the Java VM will load the specified factory class and execute
the method in the class declared as:
class <factory_class_name>
implements Preprocessor {
public static Preprocessor createPreprocessor (String arg)
where Preprocessor is an interface defined as:
package hp.javatools.bytecode;
public interface Preprocessor {
public abstract byte[] instrument (String name, byte[] klass); }
The VM will pass the <arguments> specified in the -Xprep option to the
createPreprocessor method as its only argument. The Preprocessor
object returned by the invocation will be saved by the VM.
For each subsequently loaded class, the VM will invoke the instrument()
method on the Preprocessor object, passing the name of the class being
loaded, and the bytecode representation of the class. The returned
array of bytes will be used by the VM as the replacement of the
original version of the class. If null is returned, the original
version of the class will be used.
-verbosegc or -verbose:gc
Prints out the result of a garbage collection to the stdout stream. At
every garbage collection, the following 5 fields are printed:
[%T %B->%A(%C), %D]
%T is "GC:" when the garbage collection is a scavenge, and "Full GC:" when
its a full garbage collection. A scavenge collects live objects from the
New Generation only, whereas a full garbage collection collects objects
from all spaces in the Java heap.
%B is the size of Java heap used before garbage collection, in KB.
%A is the size after garbage collection, in KB.
%C is the current camillisecondshe entire Java heap, in KB.
%D is the duration of the collection in miliseconds.
-Xverbosegc<options>
To better understand how garbage collection works in the HotSpot JVM, we recommend the article
"Improving Java Application Performance and Scalability by Reducing Garbage Collection Times and Sizing Memory Using JDK 1.4.1" (November 2002) by Nagendra Nagarajayya and J. Steven Mayer. The article describes garbage collectors in SDK 1.4.x, however it also covers the older collectors used in 1.3.x.
In addition, we recommend HP's tool HPjtune, which graphically displays information contained in an Xverbosegc log.
This option prints out detailed information about the spaces within
the Java Heap before and after garbage collection.
The syntax of the option is:
-Xverbosegc[:help]|[0|1][:file=[stdout|stderr|<filename>]]
:help prints this message.
0|1 controls the printing of heap information:
0 Print only after each full GC
1 (default) Print after every Scavenge and Full GC
:file=[stdout|stderr|<filename>] specifies output file
stderr (default) directs output to standard error stream
stdout directs output to standard output stream
<filename>
file to which the output will be written
At every garbage collection, the following 18 fields are printed:
<GC: %1 %2 %3 %4 %5 %6 %7 %8 %9 %10 %11 %12 %13 %14 %15 %16 %17 %18 >
1: Indicates the cause of the garbage collection.
-1: indicates a scavenge (during a scavenge only objects from
the New space are collected)
0-6: indicates a full garbage collection (during a full garbage
collection objects from all areas are collected)
The code indicates the reason for the full garbage collection as follows:
Reason:
0: Call to System.gc()
The call was made by the application.
1: Old Generation full
An object was to be allocated in the Old Generation, but there
was no room there.
2: Permanent Generation full
The heap area holding the reflection objects (representing Java
classes and methods) was full.
3: Train Generation full
Reserved for Java Virtual Machine developers
4: Old generation expanded on last scavenge
Due to implementation reasons, if the Old Generation expanded
on last scavenge, no more scavenges can be performed reliably
before the next full garbage collection.
5: Old generation too full to scavenge
An object was to be allocated in the New Generation, but there
was no room there. However, the VM has determined that the Old
Generation was likely too full for a scavenge to compete without
expanding the Old Generation. Therefore a full garbage collection
was performed rather than a scavenge.
6: FullGCAlot
Reserved for Java Virtual Machine developers.
%2: The time elapsed between the Java program start and the start of this
garbage collection event.
%3: Garbage collection invocation. This is the sequential number (count) of the
garbage collection event. Counts of Scavenge and
Full GCs are maintained separately.
%4: Size of the object allocation request that forced the GC, in bytes.
%5: Tenuring threshold - determines how long the new born object
remains in the New Generation.
The report includes the size of each space:
Occupied before garbage collection (Before)
Occupied after garbage collection (After)
Current capacity (Capacity)
All are in bytes.
Eden sub-space (within the New Generation)
%6: Before
%7: After
%8: Capacity
Survivor sub-space (within the New Generation)
%9: Before
%10: After
%11: Capacity
Old Generation
%12: Before
%13: After
%14: Capacity
Permanent Generation (Storage of Reflective Objects)
%15: Before
%16: After
%17: Capacity
%18: Duration of the garbage collection in seconds.
FastSwing
FastSwing is an HP feature which provides significant performance
improvement for Swing Applications on a Remote X-Server.
Remote X-Servers include X-Terminals, PC-XServers like Exceed
and Reflection X and remote UNIX workstations.
To use this feature invoke java or appletviewer as follows:
/opt/java1.3/bin/java -Dhp.swing.useFastSwing=true MyApp
or
/opt/java1.3/bin/appletviewer -J-Dhp.swing.useFastSwing=true applet.html
Currently we recommend using this feature only for Remote displays as
it has the following caveat:
Double-buffered Swing Components cannot perform Graphics2D operations with
the FastSwing feature turned on. When doing so you will get the following
exception:
java.lang.ClassCastException: sun.awt.motif.X11OffScreenImage
at BezierAnimationPanel.run(BezierAnimationPanel.java:223)
at java.lang.Thread.run(Unknown Source)
large Java heap sizes
expanding heap size in native applications (hp-ux 11.0, 11i PA-RISC)
If you embed libjvm in a native application, and wish to use a large
Java heap, you need to ensure that enough private data space is enabled.
On HP-UX 11.0 and 11i PA-RISC, by using HP-UX's EXEC_MAGIC linked with "-N" you can
expand your available memory space from 1GB to around 1.7GB.
HP-UX 11.0 PA-RISC
With the installation of the required patches shown below (or their superseded
patches), you can get larger Java heap by using the command below.
Required Patches: PHKL_20228, PHKL_23409, PHKL_26800, PHKL_26136
For 1500MB to 2400MB of Java heap:
chatr +q3p enable <executable name>
HP-UX 11i PA-RISC
With the installation of the required patch shown below (or its
superseded patch), you can get larger Java heap by using the commands below.
Required Patch: PHKL_25614 (or its superseded patch)
For 1500MB to 2400MB of Java heap:
chatr +q3p enable <executable name>
For 2400MB to 3 GB* of Java heap:
chatr +q3p enable +q4p enable <executable name>
* In our next 1.3 release, this number will be 3.8 GB.
See also "Application Dependent Considerations When Using Large Heap Size" in these release notes.
expanding heap size (hp-ux 11i PA-RISC)
Hotspot 1.3.1 now supports heaps up to 3.0 GB on HP-UX 11i, with
the installation of the patch shown below.
For Java invoked from the command line on HP-UX 11i, Java will
automatically choose an appropriate executable.
Required patch: PHKL_25614 (or its superseded patch)
For heaps less than 1500MB, the executable is 'java'.
For heaps greater than or equal to 1500MB, and less than 2400MB
the executable is 'java_q3p'.
For heaps of 2400MB to 3.0 GB*, the executable is 'java_q4p'
.
* In our next 1.3 release. this number will be 3.8 GB.
You do not need to directly invoke these programs.
Just invoke 'java' as usual, and the appropriate program will be run
for you.
In addition, be aware that if you wish to use very large
heaps, because of segmentation in the HP-UX virtual address space, when
the Java heap is larger than 3000MB, either new space (-Xmn) or old space
(-mx minus -Xmn) must be approximately 850MB or less.
See also the next section, "Application Dependent Considerations When
Using Large Heap Size."
application dependent considerations when using large heap size
Thread stacks and C heap are allocated from the same address space as the
Java heap, so if you set the Java heap too large, new threads may not start
correctly. Or some other part of the runtime or native methods may suddenly
fail if the C heap cannot allocate a new page. An application may start up
correctly with a 1.7 GB heap, but this does not necessarily mean it's going
to work correctly.
For example, if you use a 1 MB stack size, and have about 80 threads in the
process, you will have 80 MB for stacks. If you have native libraries, you
would probably add another 64 MB for C heap. You have now used a total of
144 MB of your heap for other things.
Since all programs have varying C heap requirements and have varying
numbers of threads, it's difficult to ascertain what the effect will be
of running the application at its limit. It's important to understand the
real requirements of your application. We recommend that you perform sizing
tests before deployment with a realistic load, while monitoring with the
-Xverbosegc option and a tool like GlancePlus.
using WDB to examine backtraces in Java thread stacks
You can now use HP's debugger WDB 3.0.01 (the Gnu Debugger gdb) to examine
backtraces containing mixed language frames (Java and C/C++) in Java thread
stacks. This will simplify debugging the VM and Java mixed-language
applications. Set the environment variable GDB_JAVA_UNWINDLIB to the pathname of the Java Unwind Share Library libjunwind.sl (PA), or libjunwind.so (IA) which is in the SDK.
The default location of the Java Unwind Library in the SDK is:
/opt/java1.3/jre/lib/PA_RISC/server/libjunwind.sl
/opt/java1.3/jre/lib/PA_RISC2.0/server/libjunwind.sl
/opt/java1.3/jre/lib/IA64/server/libjunwind.so
For example, in ksh, you should set the environment variable like this:
PA1.1 machines:
export GDB_JAVA_UNWINDLIB=/opt/java1.3/jre/lib/PA_RISC/server/libjunwind.sl
PA2.0 machines:
export GDB_JAVA_UNWINDLIB=/opt/java1.3/jre/lib/PA_RISC2.0/server/libjunwind.sl
Itanium Processor Family machines:
export GDB_JAVA_UNWINDLIB=/opt/java1.3/jre/lib/IA64/server/libjunwind.so
If you installed the SDK in a location other than the default,
you would substitute the non-default location for "/opt/java1.3"
in the above commands. Then use WDB as usual to debug your Java
applications or core files. See the tutorial slides on Debugging Native Code with gdb (WDB) (PDF, 245KB) for help on how to use the new Java stack unwind functionality.
Asian TrueType fonts and Asian locales
The SDK now supports HP-UX Asian TrueType fonts, with the installation of patches.
For information on which HP-UX patches you need for each language
and for additional documentation on fonts, please see the
document HP-UX Fonts and the Java™ Runtime Environment.
The following Asian Locales are now supported by HP's 1.3.1.06 SDK with TrueType fonts.
| | |
| ja_JP.SJIS | | Japanese with Shift-JIS encoding |
| ja_JP.eucJP | | Japanese with JIS EUC encoding |
| ko_KR.eucKR | | Korean with KSC5601 EUC encoding |
| zh_CN.gb18030 | | Simplified Chinese with GB18030 encoding
(supported only on HP-UX 11i) |
Our next version, SDK 1.3.1.07, will support the following Asian locales.
| | |
| zh_CN.hp15CN | | Simplified Chinese, with GB2312 EUC encoding |
| zh_TW.big5 | | Traditional Taiwan Chinese with Big5 encoding |
| zh_TW.eucTW | | Traditional Taiwan Chinese with CNS11643 encoding (planes 1-3) |
| zh_HK.hkbig5 | | Traditional HongKong Chinese with Big5 HK encoding |
|
