These Release Notes are provided on the software and as a standalone file
on this website. The website version has the most up-to-date information.
The HP-UX SDK, for the Java 2 Platform Version 1.3 release provides the tools for developing and deploying Java™ applications on PA-RISC and Itanium processor based workstations, HP
server series rp5400, rp7400, and rp8400, and Superdome with HP-UX 11.0 PA-RISC and 11i PA-RISC.
table of contents
features
installation
usage documentation
problem fixes and known issues
features
SDK 1.3.1.02
The 1.3.1.02 version of the HP-UX SDK, for the Java™ 2 Platform,
HotSpot 1.3.1 Edition contains bug fixes and enhancements, which are
described in the "Problem Fixes and Known Issues" section at the end of this
document. It also provides the functionality for using HP's
debugger WDB 3.0
for Java stack unwind support. The 1.3.1.02 version of the HP-UX SDK includes
Sun Microsystems' release 1.3.1_01.
version numbering
Starting with HotSpot 1.3.1, HP
uses the same version
numbering scheme for HotSpot as for the SDK, following JavaSoft's
convention.
HotSpot version 1.3.1 server JVM
This SDK 1.3.1 release includes the next generation HotSpot 1.3.1
server JVM (the default) and the Classic VM. See the
note above on version numbering.
The HotSpot 1.3.1 Server JVM for HP-UX 11.0 and 11i is suitable for both
client and server workloads. We invoke the Server VM with configuration
options that suit client-side applications. All the -X options that were
in HotSpot 1.0.1 are included in HotSpot 1.3.1.
The HP-UX SDK, for the Java 2 Platform, HotSpot 1.3.1 Edition includes all
of the standard Java 2 SDK Tools. The tools include appletviewer
(with a graphical user interface), extcheck, jar, java, javac, javadoc,
javah, javap, jdb and oldjdb (only for -classic mode), rmic, rmid,
rmiregistry, serialver, keytool, jarsigner, policytool, native2ascii,
tnameserv, and idlj
The HotSpot 1.3.1 Server JVM provides a number of improvements over
the existing HotSpot 1.01 and Classic runtime environments:
Improved performance
Full implementation of Java VM Debugging Interface (JVMDI)
Support for Java VM Profiling Interface (JVMPI)
Support for HP's
debugger WDB 3.0.01 for Java stack unwind
Support for the -Xeprof option for HPjmeter
Introduces a new option, -Xrs, which reduces the use of
operating system signals by the Java Virtual Machine
Large heap size (HP-UX 11i) PA-RISC
Full implementation of JVMDI and JPDA allows you to run HotSpot instead of Classic when using the 1.3 SDK with numerous tools such as TogetherSoft Control Center, Code Warrior, Oracle JDeveloper,
IBM Visual Age, Netbeans, JDE, MetaMata, Tek. Tools, Elixier IDE, BlueJ, JIG, JSwat Project, Swing Debugger, and the sample debugger jdb that ships with SDK 1.3.
Support for JVMPI means that it is possible to profile java code with the
HotSpot 1.3.1 VM. Therefore, you can extract more accurate runtime profiles.
Some of the tools based on JVMPI include: hprof (-Xrunhprof), JProbe,
JUM, and OptimizeIt. (Note: Although -hprof provides some stack trace
information not found in -Xeprof, the latter can sometimes be more useful
for performance tuning.) For more information on JVMDI and JPDA, go to
http://java.sun.com/j2se/1.3/docs/guide/jpda/architecture.html
You can now use HP's
debugger WDB 3.0.01 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.
For details, see "using WDB to debug the JVM" in these release notes.
The -Xrs option is fully documented at:
http://java.sun.com/j2se/1.3/docs/tooldocs/solaris/java.html
This release continues to support a 100% Java compatible environment.
previous 1.3 releases
The HP-UX SDK HotSpot 1.01 Edition version 1.3.0.00 included the new
features of the standard version 1.3 of the Java 2 platform. The
1.3.0.01 version was a maintenance release that contained defect fixes.
The performance, tool support, and tool enhancements are documented
at http://java.sun.com/products/jdk/1.3/docs/relnotes/features.html.
The complete list of features of the standard version 1.3 is documented
at http://java.sun.com/reference/docs/index.html#guide.
The 1.3.0 release contained the following options and features:
Xnocatch option which disables the Java "catch-all" signal handler.
HP-UX's FastSwing feature for significant performance improvement for
Swing Applications on a Remote X-Server.
JPDA support for both HotSpot and Classic VMs. The JPDA includes the
Java Debug Interface (JDI), the Java Debug Wire Protocol (JDWP), and
Java Virtual Machine Debug Interface (JVMDI). A sample debugger based on
JPDA is provided in /opt/java1.3/bin/jdb. The original jdb product has
been moved to /opt/java1.3/bin/oldjdb. Java source code for
the sample debuggers is located in examples.jar in /opt/java1.3/demo/jpda
and is unsupported.
support for the APIs core to the Java 2 platform: Java Foundation Classes
(JFC), Security, Java IDL, JDBC(tm), JavaBeans(tm), Remote Method Invocation
(RMI), Java 2D, and the Collections Framework.
non-blocking I/O Poll API for Java in the com.hp.io package.The packages
included in the APIs core to the Java 2 platform are
described at: http://java.sun.com/products/jdk/1.3/docs/api
JavaSoft idlj compiler which produces CORBA 2.3 compliant code.
Refer to http://java.sun.com/reference/docs/index.html
for more information.
The Java Naming and Directory Interface (JNDI) that makes it possible
to have a federated naming service as part of your application. Refer to
http://java.sun.com/products/jdk/1.3/docs/guide/jndi/index.html
for more information.
JavaSoft ORB Support updated to CORBA 2.3.2 compliancy, with
new feature specified "objects passed by value." Refer to the OMG
documents at http://www.omg.org/ for more information on this CORBA version.
New RMI run-time classes to provide greater performance and functionality
for RMI applications running over the JRMP protocol.
New RMI run-time classes are to allow RMI applications
to run over the IIOP protocol.
New rmic compiler that understands the "-iiop" option which produces
stub and skeleton files that communicate via the IIOP protocol. Refer to
http://java.sun.com/docs/index.html
for more information.
installation
patches
Operating system patches should be installed before you install the software.
To determine which patches have been installed on your machine,
login as root and check your machine with: /usr/sbin/swlist -l product
For the most up-to-date list of required and recommended patches,
and instructions on where to obtain them, see Patch Information. Please install any dependency patches as well. These will be listed on the IT Resource Center web page from where you download the patch.
minimum system recommendation
Users will get the best performance with HP
server series rp5400, rp7400, rp8400,
and Superdome, and PA-8600-based workstations. The recommended minimum system for running Java applications is a PA-RISC 2.0 system.
installation instructions
If you download the software from the website, you need approximately
100 MB of disk space on your system to install the software.
The HP-UX SDK, for the Java™ Platform installs
under /opt/java1.3.
As root user, use the SD-UX swinstall command to install the software:
/usr/sbin/swinstall
It will lead you through the installation. Change Source Depot Type
to "Local Directory" and Source Depot Path to /tmp/<filename>.
(If you used a directory other than /tmp in the previous step,
replace /tmp with that directory name.) We recommend you select
the "Reinstall filesets" and unselect the "Mount filesystems"
option from the options menu.
WARNING: Do not unarchive rt.jar, il8n.jar, jpda.jar, and tools.jar.
These files are needed by the SDK tools and the runtime environment.
Add the directory /opt/java1.3/bin to your PATH.
For information on setting important system parameters required for correct
execution of Java programs see the Programmer's Guide for Java™ 2.
file structure
The diagram below displays an abbreviated form of the file structure:
The tools install under opt/java1.3/bin and the libraries
install under opt/java1.3/lib. The tools.jar file contains the classes for supporting
the tools and utilities. The file dt.jar contains the DesignTime
archive of BeanInfo files.
The jre directory includes the runtime environment. The file rt.jar contains
the runtime classes for the core API. The file il8n.jar contains the
internationalization and localization classes and files. The security
directory contains security management files. The PA_RISC and PA_RISC2
directories contain the shared libraries used by the HP-UX platform.
The file src.jar contains an archive of source files for the core API for
informational purposes. To view the files, enter the command:
$ jar xvf src.jar.
The include directory contains the header files for supporting JNI and
JVMDI.
usage documentation
For additional information see the Programmer's Guide for Java™ 2.
The Java 2 Platform, Standard Edition, v 1.3 API Specification is
provided at http://java.sun.com/j2se/1.3/docs/api/index.html.
Note: Only the java.x packages are supported.
Below are some additional documentation notes.
supported tools and options
To run a tool on HP-UX, either use the full path name or add the path
to the startup file. For example, for javac, on the command line you
could enter: /opt/java1.3/bin/javac yourfile.java. You could alternatively
add /opt/java1.3/bin to your PATH statement and on the command line
enter: javac yourfile.java
The HotSpot technology accepts all of the standard tools and options. The standard tools and the standard documentation references are noted below:
The appletviewer tool is documented at
http://www.java.sun.com/products/jdk/1.3/docs/tooldocs/solaris/appletviewer.html
CLASSPATH is documented at http://www.java.sun.com/products/jdk/1.3/docs/tooldocs/solaris/classpath.html
The jar tool is documented at
http://www.java.sun.com/products/jdk/1.3/docs/tooldocs/solaris/jar.html
The java tool is documented at
http://www.java.sun.com/products/jdk/1.3/docs/tooldocs/solaris/java.html
The javac tool is documented at
http://www.java.sun.com/products/jdk/1.3/docs/tooldocs/solaris/javac.html
The javadoc tool is documented at:
http://www.java.sun.com/products/jdk/1.3/docs/tooldocs/solaris/javadoc.html
The javah tool is documented at:
http://www.java.sun.com/products/jdk/1.3/docs/tooldocs/solaris/javah.html
The javap tool is documented at:
http://java.sun.com/reference/docs/index.html
The jdb (JPDA) jdb tool is documented at:
http://java.sun.com/docs/index.html
The extcheck tool is documented at:
http://java.sun.com/reference/docs/index.html
The rmic tool is documented at:
http://java.sun.com/reference/docs/index.html
The rmiregistry tool is documented at:
http://java.sun.com/reference/docs/index.html
The rmid tool is documented at:
http://java.sun.com/reference/docs/index.html
The serialver tool is documented at:
http://java.sun.com/reference/docs/index.html
The native2ascii tool is documented at:
http://java.sun.com/reference/docs/index.html
The keytool tool is documented at:
http://java.sun.com/reference/docs/index.html
The jarsigner tool is documented at:
http://java.sun.com/reference/docs/index.html
The policytool tool is documented at:
http://java.sun.com/reference/docs/index.html
The tnameserv tool is documented at:
http://java.sun.com/reference/docs/index.html
The idlj tool is documented at:
http://java.sun.com/reference/docs/index.html
additional HotSpot option information
The HotSpot technology accepts all of the standard options. The
HotSpot technology supports the following non-standard -X options
(Non-standard options are subject to change in future releases):
-X
Prints out a brief usage message describing the non-standard options.
-Xaprof
Enable the AllocationProfiler, a simple allocation profiler for Java.
The profiler collects and prints the number and total size of instances
allocated per class, including array classes. The profiler is currently
global for all threads.
-Xbatch
Disables background compilation. If compilation of a large method
is taking a long time, the performance engine will revert to
interpreting the method. It 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.
-Xbootclasspath:<
bootclasspath>
Specify a colon-separated list of directories, JAR archives,
and ZIP archives to search for boot class files. The specified boot
class libraries will be used instead of the boot class files in the
jre/lib/rt.jar archive normally used by the Java 2 software.
-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 performance.
-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 adaptive compiler
will not be present in this mode.
-Xmn
Set the Java new generation heap size (for example: -Xmn64m). The
"new generation" is the first generation in HotSpot's generational
garbage collector. This option replaces the option -XX:NewSize=N.
-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 5248KB. Examples:
-Xms4194304
-Xms4096k
-Xms4m
-Xmx
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
-Xnoclassgc
Disables class garbage collection.
-Xprof (Excerpt below from Sun Microsystems' documentation.)
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.
-Xrs (SDK for hp-ux version 1.3.1 and later)
Reduces use of operating-system signals by the Java virtual machine (JVM), allowing for orderly shutdown of a Java application. Allows user cleanup code (such as closing database connections) to run at shutdown, even if the JVM terminates abruptly. For more information, see Javasoft's documentation at: http://java.sun.com/j2se/1.3/docs/tooldocs/solaris/java.html.
Specify the size of stack for each new Java thread. The default
Java thread stack size is 512 KB. This flag is appropriate for programs
that have small thread stack size requirements and/or create several
thousand threads, potentially running out of virtual memory. Program
threads that overflow the allocated stack will receive
java.lang.StackOverFlowException.
| Defaults: | -Xss512k (Java 1.3 and 1.4 32-bit mode) |
| | -Xss1m (Java 1.4 64-bit mode) |
Using this command instructs the JVM not to complain if the application
installs signal handlers.
-XX:MaxNewSize=<size> (not supported on 1.3)
(excerpt from http://java.sun.com/docs/hotspot/VMOptions.html)
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: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:NewSize=<
size>
(excerpt from http://java.sun.com/docs/hotspot/VMOptions.html)
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:+UseCompilerSafepoints (PA-RISC 1.3.1, 1.4 and later, Itanium 1.4.2 and later)
Enables compiler safe points. In this version, 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.
For patch information, 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 version, 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. For example, if the VM is executing a method that has
a loop with a large number of iterations, an intra-method hotspot will
occur. To get better performance, the method should run in compiled mode
instead of interpreted mode. If you enable on stack replacement,
you should also enable compiler safe points (see the previous section).
-XX:+UseSIGUSR2
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 at: Programmer's Guide for Java™ 2
Noteworthy HP
specific options and features for Java 2 version
1.3 include the following:
-pa11
-Xeprof
-Xnocatch
-Xprep
-verbosegc
-Xverbosegc
and the FastSwing feature.
These are described below.
-pa11 option
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.
-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 capacity of the 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 to 3.8 gb in native apps
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.
For both HP-UX 11.0 and 11i, by using HP-UX's EXEC_MAGIC linked with
"-N" you can expand your available memory space from 1GB to around 1.7GB.
On HP-UX 11i, with the installation of Patch PHKL_25614, you can get
larger Java heap by using the commands below.
For more information on installing patches see Patch Information.
For 1500MB to 2400MB of Java heap, use this command:
chatr +q3p enable <executable name="name">
For 2400MB to 3.8GB of Java heap, use this command:
chatr +q3p enable +q4p enable <executable name="name">
expanding heap size to 3.8 gb (hp-ux 11i)
Hotspot 1.3.1 now supports heaps up to 3.8 GB on HPUX 11.i, with
the installation of patch PHKL_25614. For more information on installing patches see Patch Information.
For java invoked from the command line on HP-UX 11i, Java will
automatically choose an appropriate executable. For heaps less than
1500MB, the executable will simply be called 'java'. For heaps greater
than or equal to 1500MB, and less than 2400MB, the executable is
'java_q3p'. If the Java heap is 2400MB or higher, the executable is
'java_q4p'. 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.
using WDB to debug the JVM
With the SDK version 1.3.1.02, 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, which is in the SDK. The default location of
the Java Unwind Library in the SDK is:
/opt/java1.3/jre/lib/PA_RISC/libjunwind.sl
/opt/java1.3/jre/lib/PA_RISC2.0/libjunwind.sl
For example, in ksh, you should set the environment variable like this:
export GDB_JAVA_UNWINDLIB=/opt/java1.3/jre/lib/PA_RISC/libjunwind.sl
(if you use PA1.1 machines), or
export GDB_JAVA_UNWINDLIB=/opt/java1.3/jre/lib/PA_RISC2.0/libjunwind.sl
(if you use PA2.0 machines).
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) for help on how to use the
new Java stack unwind functionality.
support for locales
The HP-UX proprietory encodings used by the following HP-UX
proprietary locales are not recognized by the runtime environment.
| ar_DZ.arabic8 | fr_FR.roman8 |
| ar_SA.arabic8 | is_IS.roman8 |
| da_DK.roman8 | it_IT.roman8 |
| de_DE.roman8 | iw_IL.hebrew8 |
| el_GR.greek8 | ja_JP.kana8 |
| en_GB.roman8 | nl_NL.roman8 |
| en_US.roman8 | no_NO.roman8 |
| es_ES.roman8 | pt_PT.roman8 |
| fi_FI.roman8 | sv_SE.roman8 |
| fr_CA.roman8 | tr_TR.turkish8 |
The following locales are supported:
| C.iso88591 | hu_HU.iso88592 |
| C.iso885915 | is_IS.iso88591 |
| bg_BG.iso88595 | is_IS.iso885915@euro |
| cs_CZ.iso88592 | it_IT.iso88591 |
| da_DK.iso88591 | it_IT.iso885915@euro |
| da_DK.iso885915@euro | ja_JP.SJIS |
| de_DE.iso88591 | ko_KR.eucKR |
| de_DE.iso885915@euro | nl_NL.iso88591 |
| el_GR.iso88597 | nl_NL.iso885915@euro |
| en_GB.iso88591 | no_NO.iso88591 |
| en_GB.iso885915@euro | no_NO.iso885915@euro |
| en_US.iso88591 | pl_PL.iso88592 |
| es_ES.iso88591 | pt_PT.iso88591 |
| es_ES.iso885915@euro | pt_PT.iso885915@euro |
| fi_FI.iso88591 | ro_RO.iso88592 |
| fi_FI.iso885915@euro | ru_RU.iso88595 |
| fr_CA.iso88591 | sk_SK.iso88592 |
| fr_CA.iso885915 | sl_SI.iso88592 |
| fr_FR.iso88591 | sv_SE.iso88591 |
| fr_FR.iso885915@euro | tr_TR.iso88599 |
| hr_HR.iso88592 | zh_CN.hp15CN |
| | zh_TW.big5 |
|
