| NOTE: Some of the usage documentation previously included in these release notes has been moved to the Java for HP-UX Programmer's Guide at Programmer's Guide for Java™ 2
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 much more.
Another change is that beginning with 1.4.2.08, we are combining the SDK, RTE,
and Runtime Plug-in release notes in this document.
For additional documentation web sites, refer to "Additional HP and Sun
documentation" in these release notes.
SDK Usage
Removing support for unwanted architectures in the RTE
Under the RTE license agreement, partners who redistribute the RTE may
remove support for unwanted architectures. Functional components may NOT
be removed under any circumstances. Beginning with this 1.4.2.05 release,
you may remove support for unwanted architectures as follows:
The following commands assume that the RTE has been installed in the standard location, i.e. /opt/java1.4/.
The swremove commands must be run as root. Use these command lines:
- On a PA-RISC or HP Integrity (Itanium) system, to remove PA_RISC 1.1 support:
/usr/sbin/swremove Jre14.JRE14-PA11 Jre14.JRE14-PA11-HS
(The -pa11 command line option will no longer work.)
- On a PA-RISC system, to remove 64-bit support:
/usr/sbin/swremove Jre14.JRE14-PA20W Jre14.JRE14-PA20W-HS
(The -d64 command line option will no longer work.)
- On an HP Integrity (Itanium) system, to remove 64-bit support:
/usr/sbin/swremove Jre14.JRE14-IPF64 Jre14.JRE14-IPF64-HS
(The -d64 command line option will no longer work.)
Support for dynamic thread local storage (TLS)
Dynamic thread local storage is fully supported on all HP Integrity (Itanium) systems, beginning with SDK Versions 1.4.2.00 and 5.0.
Dynamic TLS is not available on any HP-UX PA-RISC system. However there is a workaround. Refer to "shl_load HotSpot libjvm problem due to TLS (PA-RISC)" in these release notes for details.
Signal Chaining Functionality
With signal chaining functionality, applications can now use signals that the JVM uses and they will not interfere with the JVM's functionality. For signal chaining, the application must load the library libjsig.sl (PA) or libjsig.so (Itanium) before libc.2.
On PA-RISC, to obtain this functionality, you need to install the patch shown below and then use LD_PRELOAD. On HP Integrity, no patch and no workaround is needed.
HP-UX 11.11 PA-RISC systems, install patch PHSS_28436 (or the patch that supersedes it)
For examples and scenarios of how to use LD_PRELOAD, refer to the Java for HP-UX Programmer's Guide at: Using Signals#chaining
Support for C++ applications built with -AA and -AP options (PA-RISC)
Java supports the -AA and -AP options to build your C++ product. On HP Itanium systems, the C++ runtime libraries support -AA and -AP by default. On HP-UX 11.0 or 11.11 PA-RISC, 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. Note that these libraries are provided as a separate download on the same page from where you download the SDK and RTE, starting at this webpage:
SDK and RTE 1.4.2.x Downloads and Documentation
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
The native application must be linked with, or must dynamically load these versions of the Java libraries if your 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.
HotSpot JVM Options
For all standard and non-standard options, please refer to the Java for HP-UX Programmer's Guide at HotSpot Technology Tools and Commands.
Garbage collectors: Parallel, Concurrent mark, and Sweep
JavaSoft has implemented new generational collectors that emphasize the
throughput of the application or low garbage collection pause times.
For a detailed look at garbage collection and the new collectors, refer to JavaSoft's documentation "Tuning Garbage Collection with the 1.4.2 Java Virtual Machine" at http://java.sun.com/docs/hotspot/gc1.4.2/index.html
Allocating physical memory and swap in the Java heap
The method of allocating physical memory and swap within the Java heap
has changed. As a result, you are likely to see higher RSS (resident set size)
memory usage when monitoring your Java processes with Glance or other tools, or your application startup may be slightly slower.
For more details on why this occurs and for examples of using key command line options, see: Allocating Physical Memory and Swap in the Java Heap.
Asian TrueType fonts and Asian locales
Asian Locales are supported by HP's 1.4 JDK with TrueType fonts. For more
details, please refer to HP-UX Fonts and the Java™ Runtime Environment.
Date/Time methods - New defaults
The HotSpot JVM uses the gettimeofday() system call to obtain date
and time information.
For performance reasons a new mechanism is used that uses the number
of CPU ticks since the application started, to calculate the current time.
As a result, changes to the system date or time using date(1), adjtime(2) 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
In the SDK Version 1.4, a SIGPROF handler to support future profiling capability is installed automatically. This may cause incompatibilities with other native code or profiling tools which use SIGPROF.
You can turn off the SIGPROF handler by using the following option -XX:+ReduceSignalUsage
However be aware that using this option also turns off the SIGQUIT handler, and you therefore will not be able to get a Java stack trace.
Closing a socket when accept or read is pending (PA-RISC) - new patch information!
Because of changes to the mechanism by which a socket is closed in the VM, for all supported HP-UX PA-RISC systems, you no longer need to use the -XdoCloseWithReadPending option we recommended in earlier releases. However for HP-UX 11.11 the following patches (or their superseded patches) are required:
PHKL_32457
PHKL_25840
PHKL_25842
PHNE_25644
PHNE_25084
For more detailed information, refer to the Java for HP-UX Programmer's Guide at HotSpot Technology Tools and Commands#socket
Compatibility with previous releases
Sun Microsystems maintains upward compatibility, therefore an application written for a 1.3 JVM will run on a 1.4 JVM. Downward compatibility is generally not supported, because new API's are introduced that cannot be run on earlier JVMs.
For a detailed description of the incompatibilities between 1.3 and 1.4, refer to http://java.sun.com/j2se/1.4/compatibility.html
Runtime Plug-In usage and configuration
You can configure the Runtime Plug-In by running the Control Panel script, which launches the Control Panel java application, or by loading ControlPanel.html in the browser. Both files are found in the directory jre/bin and jre/, respectively, under the directory where the Runtime Plug-in has been installed.
The Control Panel application generates a file,
$HOME/.java/deployment/deployment.properties.
This file contains, among other settings, the path to the RTE to be used by the Runtime Plug-in for HP-UX when the browser loads an applet from a Runtime Plug-in enabled html page. If the Plug-in is installed in the default location, this setting is stored in the key:
javaplugin.jre.path=/opt/java1.4/jre
No environment variables are necessary for configuring the Runtime Plug-In for HP-UX, Java Edition. However, you may optionally use the following environment variables.
MOZ_PLUGIN_PATH
You can use the MOZ_PLUGIN_PATH environment variable to direct the Mozilla browser to search alternate directories for plug-in libraries.
Note: The entries in the $HOME/.java/deployment/deployment.properties file supersede those of MOZ_PLUGIN_PATH when locating the RTE.
CLASSPATH
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.
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.
Enabling HTML pages to use the Runtime Plug-in for HP-UX
The first time the Mozilla browser loads an applet from a Runtime Plug-in-enabled HTML page, it will download and install the Runtime Plug-in for HP-UX. Sun Microsystems Inc. has provided some additional tools to assist users in using Plug-in products. They have provided a converter to automate the enabling on HTML pages. They also provide an HTML specification for users who wish to enable their HTML pages manually.
Information on Sun Microsystems HTML converter and specification is available at http://java.sun.com/reference/docs/index.html. You may want to use it to modify your HTML pages to specify use of the Runtime Plug-in for HP-UX, Java Edition, version 1.4.x instead of the default browser version of the HP-UX Runtime Environment for Java.
GC log-rotation support on SDK 1.4.2.23
Prior to SDK 1.4.2.23, when using GC logging options (for example, -Xverbosegc or
-Xloggc), GC data is written to a single file of unlimited size. Starting with SDK 1.4.2.23, 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 HP and Sun documentation
The following web sites have additional information:
Java man pages (located at/opt/java1.5/man)
|
