HP-UX 11i Java™ JDK/JRE Version 6.0.22 Release Notes

enabled and PHKL_35448. With this change, the initial resident memory or RSS (Resident

Set Size) value of the java process is much smaller.

To get the same reduced initial RSS value on JDK 5.0 or on 6.0 releases prior to 6.0.03,

use the following option:

-XX:+ForceMmapReserved

Interruptible I/O

The Thread.interrupt() method can interrupt some blocking I/O operations,

resulting in InterruptedIOException thrown by the target thread and leaving socket or file

streams in an inconsistent state. This behavior is the same as on the Solaris platform, but

different from Windows and Linux.

On HP JDK 6.0 (and JDK 1.5.0.08 and later), this function is controllable by the JVM

option UseVMInterruptibleIO, which is on by default.

To turn off interruptible I/O, use the option:

-XX:-UseVMInterruptibleIO

Beginning in JDK 7.0, the default is changed, and UseVMInterruptibleIO is off by

default.

Also see "UseVMInterruptibleIO" at http://www.oracle.com/technetwork/java/javase/

releasenotes-142123.html and http://bugs.sun.com/bugdatabase/view_bug.do?

bug_id=4385444.

Known issues

NOTE: On HP Itanium servers, if the Aries option is set to -pa_os_cpu globally, HP-UX

Java incorrectly runs PA binaries instead of IA binaries. This happens silently, without

any messages. The performance degrades by 2-3 times. The problem is fixed for JDK

releases beginning with 6.0.01, but it is seen across previously released JDKs.

The following are known problems for HP-UX 11i Integrity and HP 9000 PA-RISC systems.

Some of the solutions require installing patches. For more information on locating and

installing patches, see the HP-UX Java Patch Information web page at:

http://ftp.hp.com/pub/softlib/hpuxjava-patchinfo/index.html

Running Java applications with hyperthreading enabled

Prior to JDK 6.0.17, java applications might crash with a SEGV in interpreter code on

systems with hyperthreading enabled. The crash usually occurs when an interpreted

method is executing one of the "fast" getfield or putfield bytecodes. This can be

determined by using gdb to analyze the core file written at the time of the crash. Use

the gdb "bt" command to examine the stack trace and find the stack frame that caused

a signal handler to be called. Then use the "frame" and "info frame" commands to

see what bytecode the errant frame was executing. For example, the excerpted gdb