HP-UX Programmer's Guide for Java 2
Table Of Contents
- Table of Contents
- 1 Introduction
- 2 HotSpot Technology Tools and Commands
- 3 Configuration for Java™ Support
- 4 Performance and Tuning
- 5 Measuring System Performance
- 6 Using Threads
- 7 Using Signals
- 8 Using Java™ 2 JNI on HP-UX
- 9 Expanding Memory
- Determine your requirements
- Memory layout under HP-UX 11.0 (PA-RISC only)
- Additional memory available under HP-UX 11i (PA-RISC only)
- Allocating physical memory and swap in the Java™ heap
- Useful key command-line options for allocating memory
- Application-dependent considerations using large heap size HP-UX 11i PA-RISC
- Expanding heap size in native applications on PA-RISC HP-UX 11.11 and later releases
- Expanding heap size in native applications on Integrity HP-UX 11.23 and later releases
- Expanding heap size in HP-UX PA-RISC
- Expanding heap size in HP-UX Integrity
- 10 Diagnosing Memory Leaks
- A JDK/JRE 6.0.n and 7.0.n Usage Notes
- Using Java 2 JNI on HP-UX
- Garbage collection
- Asian TrueType fonts and Asian locales
- Date/Time methods defaults
- Profiling
- Compatibility with previous releases
- Java Cryptography Extension (JCE) policy files
- Configuring the Java Runtime Plug-In
- CLASSPATH environment variable
- Java Web Start technology usage
- Upgrading from a previous Java Web Start version
- IPv6 support
- Allocation Site Statistics and Zero Preparation -Xverbosegc
- JDK 6.0.04 flags
- GC log-rotation support
- NUMA collector enhancements
- ThreadDumpPath support
- Garbage-First garbage collector (-XX:+UseG1GC)
- jmap, jinfo, and jstack tools included in JDK 6.0.03
- Additional Java Web Start documentation
- B JDK/JRE 5.0.n Usage Notes
- Using Java 2 JNI on HP-UX
- Garbage collectors: Parallel and Concurrent Mark Sweep
- Allocating physical memory and swap in the Java heap
- Asian TrueType fonts and Asian locales
- Date/Time methods defaults
- Profiling
- Closing a socket (PA-RISC only)
- Compatibility with previous releases
- Java Cryptography Extension (JCE) policy files
- Allocation Site Statistics and Zero Preparation -Xverbosegc
- IPv6 support on Java 5.0
- GC log-rotation support in 5.0
- ThreadDumpPath support in 5.0
- Dynamically loaded libraries in 5.0
- Performance improvement for String.intern()
- Configuring the Java Runtime Plug-In
- CLASSPATH environment variable
- Java Web Start technology usage
- C SDK/RTE 1.4.2.n Usage Notes
- Removing support for unwanted architectures in the JRE
- Support for dynamic thread local storage (TLS)
- Signal Chaining functionality
- Using Java 2 JNI on HP-UX
- HotSpot JVM options
- Garbage collectors: Parallel and Concurrent mark sweep
- Allocating physical memory and swap in the Java heap
- Asian TrueType fonts and Asian locales
- Date/Time methods defaults
- Profiling
- Closing a socket when accept or read is pending (PA-RISC) - new patch information!
- Compatibility with previous releases
- Runtime Plug-In usage and configuration
- GC log-rotation support
- ThreadDumpPath support
- D Additional Resources
- Index
The JVM installs signal handlers for SIGHUP, SIGINT, and SIGTERM, and if these are
overridden, the shutdown hooks will not be executed. Note that for any of these signals
a handler is not installed if the signal handlers' disposition is set to SIG_IGN. For
instance, this could be as a result of starting the application using nohup(1).
SIGABRT, SIGBUS, SIGILL, SIGIOT, SIGEMT, SIGSEGV, SIGSYS, SIGTRAP
(synchronous signals) and SIGXCPU and SIGXFSZ (asynchronous signals) cause
termination of the JVM. If the -Xnocatch option is used, the termination is silent and
a core file is produced. If the -Xnocatch option is not used, a dump of all of the Java™
stacks is written to stderr, the JVM terminates with a SIGABRT and produces a core
file.
SIGQUIT is an asynchronous signal that is intercepted by the JVM. It causes the JVM
to print the Java™ call stack for each active Java™ thread in the process to standard
error. All locks held are printed below the name of the method in which the lock was
acquired. Similarly, a lock trying to be acquired is printed. The JVM resumes execution
after all information has been written.
SIGPIPE is a synchronous signal that is ignored by the JVM.
SIGFPE is a synchronous signal used by the JVM and the HotSpot JVM to implement
its runtime.
SIGALRM is an asynchronous signal that is intercepted by the Java™ 2 JVMs.
SIGUSR1 is a synchronous signal used internally by the JVM runtime.
HotSpot options that control signals
The following options to the HotSpot JVM control the signals used by the JVM and
installation of other signal handlers. The Classic JVM does not accept -XX options.
Note that -XX options are non-standard options and are subject to change in future
releases.
-XX:+AllowUserSignalHandlers
Instructs the HotSpot JVM not to complain if the native code libraries install signal
handlers. This only matters if the handlers were installed when the VM is booting.
-Xusealtsigs (Replaces the -XX:+UseSIGUSR2 option beginning with SDK
1.4.1.00, 1.4.2.00, and 1.3.1.13)
Replaces the -XX:+UseSIGUSR2 option. Instructs the JVM to avoid using SIGUSR1
and SIGUSR2 for internal operations (like Thread.interrupt() calls). In SDK 1.4.1
and later, by default the JVM uses both SIGUSR1 and SIGUSR2. (In SDK 1.3.1.13 only
SIGUSR1 is used.) If -Xusealtsigs is used, then two signals halfway between
SIGRTMIN and SIGRTMAX will be chosen instead. This allows you to implement third
party middleware applications better that may want to use SIGUSR1 or SIGUSR2 for
other purposes in their native code.
-XX:+UseSIGUSR2 (for SDKs 1.4.0.x and 1.3.1.00 through 1.3.1.12)
HotSpot options that control signals 41