|
The Java for HP-UX Programmer's Guide at Programmer's Guide for Java™ 2 contains usage documentation for developers. There you will find information on HotSpot options, HP-specific options and features, suggestions and examples for allocating memory, how to use wdb to examine backtraces in Java threads, code examples for using Java Native Interface, and more.
For more information, refer to Sun Microsystems' Java HotSpot VM Options at http://java.sun.com/docs/hotspot/VMOptions.html.
Removing support for unwanted architectures in the JRE
Under the JRE license agreement, partners who redistribute the JRE may remove support for unwanted architectures. Functional components may NOT be removed under any circumstances. You may remove support for unwanted architectures as explained below.
The following commands assume that the JRE has been installed in the standard location, that is, /opt/java6/.
- On PA-RISC, to remove 64-bit support:
/usr/sbin/swremove Jre60.JRE60-PA20W Jre60.JRE60-PA20W-HS
- On HP Integrity, to remove 64-bit support:
/usr/sbin/swremove Jre60.JRE60-IPF64 Jre60.JRE60-IPF64-HS
- PA filesets are not installed by default on HP Integrity. If you have installed them for some reason, they can be removed with:
/usr/sbin/swremove Jre60.JRE60-PA20 Jre60.JRE60-PA20-HS \
Jre60.JRE60-PA20W Jre60.JRE60-PA20W-HS
Using wdb to examine backtraces in Java thread stacks
You can use HP's wdb 3.0.01 or later debugger (the GDB Debugger gdb) to examine backtraces containing mixed language frames (Java and C/C++) in Java thread stacks. This simplifies debugging JVM and Java mixed-language applications.
Set the environment variable GDB_JAVA_UNWINDLIB to the path name of the Java Unwind Shared Library libjunwind, which is in the JDK. The default location of the Java Unwind Library in the JDK is:
/opt/java6/jre/lib/PA_RISC/server/libjunwind.sl
/opt/java6/jre/lib/PA_RISC2.0/server/libjunwind.sl
/opt/java6/jre/lib/PA_RISC2.0W/server/libjunwind.sl
/opt/java6/jre/lib/IA64N/server/libjunwind.so
/opt/java6/jre/lib/IA64W/server/libjunwind.so
Here are two examples setting the environment variable (in the ksh):
For 64-bit PA2.0 machines:
export GDB_JAVA_UNWINDLIB=/opt/java6/jre/lib/\
PA_RISC2.0W/server/libjunwind.sl
For 64-bit HP Integrity machines:
export GDB_JAVA_UNWINDLIB=/opt/java6/jre/lib/\
IA64W/server/libjunwind.so
If you installed the JDK in a location other than the default, substitute the non-default location for /opt/java6 in the above commands. Then use wdb as usual to debug your Java applications or core files. See the tutorial slides on debugging native and Java code with wdb at Performance Tuning, Tutorials, & Training for help on how to use the new Java stack unwind functionality.
Support for C++ applications built with -AA and -AP options (PA-RISC) only
Java supports the -AA and -AP options to build C++ applications. On HP-UX 11.11 and later releases on PA-RISC systems, C++ uses the -AP runtime option by default. If you are using the ANSI Standard C++ runtime (-AA) option in an application that loads Java, you need to use the -AA version of libjvm and libfontmanager.
These are the Standard C++ Runtime version of these libraries:
./jre/lib/PA_RISC2.0/libjvm_v2.sl
./jre/lib/PA_RISC2.0W/libjvm_v2.sl
./jre/lib/PA_RISC2.0/libfontmanager_v2.sl
./jre/lib/PA_RISC2.0W/libfontmanager_v2.sl
Any native application must be either linked with or dynamically load these versions of the Java libraries if the C++ application is compiled using -AA.
The Standard C++ version of the JVM libraries are supported for PA_RISC2.0 and PA_RISC2.0W architectures only.
If the JVM is invoked through the standard Java driver, then use the -V2 option to use the Standard C++ runtime. For example:
java -V2 <javaprog>
Using Java 2 JNI on HP-UX
For C and C++ applications, it is important to link with the -mt (multithread) option if the application calls a Java VM. Both executables and shared libraries must be linked with -mt. Use of -mt must be consistent during both compilation and linking. For more information, refer to the Native (non-Java) calling Java methods section in the Programmer's Guide.
If you embed libjvm in a 32-bit native application and wish to use a large Java heap, you must link with the -N option. Refer to the Expanding heap size in native applications on PA-RISC HP-UX 11.11 and later releases and Expanding heap size in native applications on Integrity HP-UX 11.23 and later releases for more information.
Garbage collection
For documentation about garbage collection in JDK 6 refer to http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html.
Asian TrueType fonts and Asian locales
Asian locales are supported by JDK 6 with TrueType fonts. For more details, refer to HP-UX Fonts and the Java™ Runtime Environment.
Date/Time methods defaults
The HotSpot JVM uses the gettimeofday() system call to obtain date and time information. For performance reasons a new mechanism that uses the number of CPU ticks since the application started is used to calculate the current time. As a result, changes to the system date or time using the date command, adjtime() function, or time synchronization utilities such as ntp will not be reflected in the date and time that the Java program returns until the process is restarted.
If your application requires that system time changes are immediately reflected, you can use the
-XX:+UseGetTimeOfDay option to tell the JVM to use the gettimeofday call instead of the new, lightweight mechanism. However you may notice a drop in performance.
Profiling
Currently a SIGUSR2 handler to support -Xeprof profiling and a SIGPROF handler to support future profiling capability are automatically installed. This may cause incompatibilities with other native code or profiling tools which use SIGUSR2 or SIGPROF. You can turn off both handlers by using the -XX:+ReduceSignalUsage option. If you do this, be aware that this option also turns off the SIGQUIT handler, and, therefore, you will not be able to get a Java stack trace.
You can turn off just the SIGUSR2 handler by using the -Xeprof:off option, thereby retaining the ability to get a Java stack trace using SIGQUIT. For more information about -Xeprof profiling, refer to the HotSpot Technology Tools and Commands chapter of the HP-UX Programmer's Guide for Java 2 at HotSpot Technology Tools and Commands.
Compatibility with previous releases
Sun Microsystems maintains upwards compatibility. Therefore, an application written for an older JVM will run on JDK 6.0. Downward compatibility is generally not supported because new APIs are introduced that do not run on earlier JVMs.
For more information about JDK 6 compatibility with JDK 5, refer to: http://java.sun.com/javase/6/webnotes/compatibility.html.
Java Cryptography Extension (JCE) policy files
Due to import control restrictions for some countries, the Java Cryptography Extension (JCE) policy files shipped with JDK 6.0 allow strong but limited cryptography to be used. These files are located at:
<Java-home>/lib/security/local_policy.jar
<Java-home>/lib/security/US_export_policy.jar
where <Java-home> is the JRE directory of the JDK or the top-level directory of the Java SE Runtime Environment. An unlimited strength version of these files indicating no restrictions on cryptographic strengths is available on the JDK website for those living in eligible countries. Those living in eligible countries may download the unlimited strength version and replace the strong cryptography jar files with the unlimited strength files.
Unlimited strength jurisdiction policy files may be downloaded from: http://java.sun.com/javase/downloads/index.jsp.
Configuring the Runtime Plug-In
For additional information on the Runtime Plug-In, refer to the Plug-In FAQs at
Java™ Runtime Plug-in (JPI) for 1.3, 1.4, 5.0, & 6.0 Frequently Asked Questions and the Sun Java Deployment Guide for 6.0.
The JPI configuration was redesigned in the 5.0 release. For more information refer to Sun Microsystems' documentation at:
http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/jcp.html
CLASSPATH environment variable
A user's CLASSPATH environment variable can be passed by the JVM by running the Control Panel and specifying either '-cp' or '-classpath' in the Java Run Time Parameter box. You need to exit and rerun the browser for this change to take effect.
Java Web Start technology usage
Java™ Web Start is an application-deployment technology, which gives you the power to launch full-featured applications with a single click from a web browser. It is located in the jre directory. Some of Java Web Start's features include:
- Runs independently of any browser, so you can shut down your browser or go to another web page and continue using your application.
- Applications deployed with Java Web Start do not require a browser interface to operate.
- Includes security features of the Java 2 platform.
The hardware and operating system requirements for using Java Web Start are the same as those recommended for Java SE platform implementation on which it runs.
Upgrading from a previous Java Web Start version
Do NOT uninstall your previous version of Java Web Start (if you have one) before installing the new version. Uninstalling the previous version will cause the download cache to be cleared and all of the previously installed Java Web Start applications will need to be downloaded again.
This version will overwrite previous installations and automatically update browsers to use this new release. In order to reactivate a previous version after installing this new release, you must reinstall the old version. The configuration files and program files folder used by Java Web Start have not changed, so all your settings will remain intact after the upgrade.
IPv6 support on Java 6.0
IPv6 is a set of Internet Protocol specifications designed to provide enhancements over the capabilities of the existing IPv4
service in terms of scalability, security, mobility, ease-of-configuration, and real-time traffic handling.
For more information, see the Sun Microsystems' Networking IPv6 User Guide for J2SDK/JRE 1.4 (http://java.sun.com/j2se/1.4/docs/guide/net/ipv6_guide/).
HP-UX 11.11 (11i v1), 11.23 (11i v2), and 11.31 (11i v3) support dual protocol stacks: IPv4 and IPv6. IPv6 is not currently supported on
HP-UX 11.0 or 11.22 (11i v1.5). In this JDK release, the IPv6 protocol stack is the default. To support IPv6, HP-UX 11.11 (11i v1)
requires HP-UX patches; HP-UX 11.23 (11i v2) and 11.31 (11i v3) do not.
For the availability of HP-UX patches required for IPv6 support on HP-UX 11i, please see:
» Patch information
» TOUR Transition
Patches for HP-UX 11i
Prior to JDK 6.0.03, the IPv4 protocol stack was the default. Beginning with JDK 6.0.03, the IPv6 protocol stack is the default.
To turn off IPv6 support, you need to set the system property as follows:
java.net.preferIPv4Stack=true
Or, at the Java™ command line, you can use the option:
-Djava.net.preferIPv4Stack="true"
Beginning with JDK 6.0.03, you can use the properties file:
{JAVA_HOME}/jre/lib/net.properties
to set
java.net.preferIPv4Stack=true
Allocation Site Statistics and Zero Preparation -Xverbosegc
NOTE: To properly view Zero Preparation -Xverbosegc and Allocation Statistics information, you must use HPjmeter
3.1 or later.
Starting with the 6.0.02 release, you can prompt the JVM to emit HP -Xverbosegc information for Java applications started without
-Xverbosegc. Zero Preparation -Xverbosegc allows you to obtain -Xverbosegc information from the JVM by sending the
running Java program a SIGPROF signal. For example, assuming the running Java process ID is 6754, then, executing
either of the two actions listed below prompts the JVM to start emitting detailed HP -Xverbosegc information:
kill -21 6754
kill -s sigprof 6754
Issuing a second SIGPROF signal to the running Java program prompts the JVM to stop emitting the -Xverbosegc information.
Similarly, issuing yet another SIGPROF signal to the running process prompts the JVM to start issuing -Xverbosegc
information one more time.
Additionally, starting with this release, and only if you had started the Java application with
-XX:+PrintAllocStatistics, when zero preparation -Xverbosegc is enabled as specified in the previous paragraph, the
JVM also emits detailed allocation site statistics.
If you start your application with -XX:+PrintAllocStatistics, and if you do not specify
-Xverbosegc, or send the running process a SIGPROF signal, then the JVM will emit allocation site statistics
to standard out when the application terminates. (That is, when the Java process stops running.) If you do not want to
wait for the application to terminate, or if the application is designed to be long running (or does not terminate), then you can
obtain allocation site statistics by sending the running Java program a SIGPROF as described above.
Unlike -Xverbosegc information emission in zero preparation mode, which is started with a SIGPROF and stopped with a second
SIGPROF, when -XX:+PrintAllocStatistics is specified, allocation site statistics is emitted every time the JVM
receives a SIGPROF.
When -XX:+PrintAllocStatistics is specified along with -Xverbosegc, allocation site statistics data are
directed to the same output specified for HP -Xverbosegc. If no output file is specified, allocation site statistics are
directed to standard out (to the terminal where the program was started from). When -XX:+PrintAllocStatistics is
specified alone (without -Xverbosegc on the command line), allocation site statistics are directed to standard out
(to the terminal).
When a SIGPROF signal is sent to a running Java process that was originally started with
-XX:+PrintAllocStatistics on the command line, the SIGPROF signal will also enable -Xverbosegc data collection
if -Xverbosegc was not specified on the command line when the program was started, and the output of both -Xverbosegc and allocation
site statistics is directed to a file created for you by the JVM. The name of the file created by the JVM has the following
format: java_<pid>.vgc. Where <pid> is the Java process id.
The following table lists all possible permutations and corresponding locations of emitted data for both allocation site
statistics and zero preparation -Xverbosegc.
| Action |
JVM Flags Specified |
Allocation Site Statistics Data Location |
| No special action taken |
-XX:+PrintAllocStatistics
-Xverbosegc |
Standard out |
| No special action taken |
-XX:+PrintAllocStatistics
-Xverbosegc:file=mydata.vgc |
Same location as -Xverbosegc data file (mydata.vgc) |
| No special action taken |
-XX:+PrintAllocStatistics |
Standard out |
'kill -21 <pid>' |
-XX:+PrintAllocStatistics |
JVM will create a file for you, file name format is: java_<pid>.vgc |
| 'kill -21 <pid>' |
-XX:+PrintAllocStatistics
-Xverbosegc |
Standard out |
| 'kill -21 <pid>' |
-XX:+PrintAllocStatistics
-Xverbosegc:file=mydata.vgc |
Same location as -Xverbosegc data file (mydata.vgc) |
| 'kill -21 <pid>' |
-Xverbosegc |
Standard out |
| 'kill -21 <pid>' |
-Xverbosegc:file=mydata.vgc |
Same location as -Xverbosegc data file (mydata.vgc) |
|
 |
|
|
Sending multiple SIGPROF signals to a running Java process produces multiple allocation site statistics dumps and
the JVM dumps the buffered data immediately after the SIGPROF is received. Allocation site statistics counters
inside the JVM are reset after each SIGPROF induced the dump of the data. HPjmeter consolidates data from
multiple allocation site statistics dumps into one report that is presented in a new tab in the -Xverbosegc data visualizer.
Allocation sites can originate from interpreted as well as compiled Java code, when specifying -XX:+PrintAllocStatistics,
and only allocations coming from compiled code are reported. The Java Virtual Machine detects and compiles the application’s
(and JDK's) most active Java methods as early as possible. Though reporting allocation sites originating from compiled code is
only incomplete from a comprehensive reporting point of view, it does always report the most active allocation sites (the sites most
likely to cause GC performance problems).
JDK 6.0.04 flags
JDK/JRE 6.0.04 contains the following new flags.
-XX:+UseAltHashPolicy
Enables an alternate internal hash function and can reduce Hash Map resizing for some applications.
This flag is enabled/disabled similarly to all –XX JVM flags; to enable it, specify
-XX:+UseAltHashPolicy on
the Java command line, and to disable it, specify
-XX:-UseAltHashPolicy on the Java command line. By default,
this option is disabled.
-DdfCacheSize=n
Caches internal computations for formatting floating point numbers where n is the size of the cache, which may provide a
performance benefit in some cases. To enable it, specify
-DdfCacheSize=n, where n is the size of the
cache. The value of n must be greater than 1 for caching to take effect. Users must be careful not to specify too
large a value for this cache. The cache is a JVM internal data structure which resides in the Java Heap, so specifying
too large a cache value might result in excessive Full GC activity, which could impact application performance. A cache
value of 200,000 for a maximum Java heap size of 3.5 GB in 32-bit mode is considered large. In 64-bit mode, users can specify
larger values for this cache. When specifying large cache values, users should also consider the overhead of cache lookup.
Lookup time increases as the size of the cache increases resulting in negative effect on performance. This caching is disabled
by default.
Additionally, the -XX:HeapDumpPath=<path/filename> option can be used to specify the heap dump
file name or a directory where the heapdump should be created. Starting with the JDK 6.0.04 release, this option can be used
with -XX:+HeapDump,
-XX:+HeapDumpOnCtrlBreak, and -XX:+HeapDumpOnly.
GC log-rotation support on JDK 6.0.05
Prior to JDK 6.0.05, when using GC logging options (for example, -Xverbosegc or
-Xloggc), GC data is written to a single file of unlimited size. Starting with JDK 6.0.05, the JVM supports
generation of multiple GC log files and rotates through the specified number of files. This allows for easier archiving
of GC data and helps limit the amount of disk space consumed by the GC log. Log rotation is also supported when using
zero-preparation Xverbosegc.
To enable log rotation, use the following option together with -Xverbosegc, -Xloggc, or zero-preparation
Xverbosegc:
-XX:GCLogLimits=M,N
M is a non-negative integer for the number of GC records per file. Each GC record corresponds
to a GC event. A value of 0 specifies an unlimited number of records per file.
N is a non-negative integer for the maximum number of files. A value of 0 specifies an
unlimited number of files.
When using this option, both M and N are required. If this option is not specified,
then the default behavior is to write a single GC log file with unlimited size.
When rotation is in effect, a sequence number is appended to the the GC filename (0 through N-1). (Examples of file names are:
filename.0, filename.1, and filename.2.)
With log rotation, when the specified maximum number of files (N) is reached, logging cycles back to the first file in the
sequence (filename.0), overwriting old GC data with new data. If the maximum number of files (N) is never reached, then no
log rotation occurs.
Examples:
Rotate between two log files, each with a maximum of 100,000 GC records:
-XX:GCLogLimits=100000,2
Maintain an unlimited number of smaller files, each with a maximum of 1,000 GC records:
-XX:GCLogLimits=1000,0
Additional Java Web Start documentation
More information, including developer documentation, can be found in Sun Microsystems' documentation at: http://java.sun.com/products/javawebstart/reference/index.html. Additionally, the Sun Java Deployment Guide for 6.0 at http://java.sun.com/javase/6/docs/technotes/guides/deployment/deployment-guide/contents.html also contains useful information.
Additional HP and Sun Java documentation
The following websites have additional information:
Java manpages (located at/opt/java6/man)
|
