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
processor in the system has a local memory that provides low access latency and high
bandwidth, and remote memory that is considerably slower to access.
In the Java HotSpot Virtual Machine, the NUMA-aware allocator has been implemented
to take advantage of such systems and provide automatic memory placement
optimizations for Java applications. The allocator controls the eden space of the young
generation of the heap, where most of the new objects are created. The allocator divides
the space into regions each of which is placed in the memory of a specific node. The
allocator relies on a hypothesis that a thread that allocates the object will be the most
likely to use the object. To ensure the fastest access to the new object, the allocator
places it in the region local to the allocating thread. The regions can be dynamically
resized to reflect the allocation rate of the application threads running on different
nodes. That makes it possible to increase performance even of single-threaded
applications. In addition, "from" and "to" survivor spaces of the young generation, the
old generation, and the permanent generation have page interleaving turned on for
them. This ensures that all threads have equal access latencies to these spaces on average.
The NUMA-aware allocator can be turned on with the -XX:+UseNUMA flag in
conjunction with the selection of the Parallel Scavenger garbage collector. The Parallel
Scavenger garbage collector is the default for a server-class machine. The Parallel
Scavenger garbage collector can also be turned on explicitly by specifying the
-XX:+UseParallelGC option.
Applications that create a large amount of thread-specific data are likely to benefit most
from UseNUMA. For example, the SPECjbb2005 benchmark improves by about 25% on
NUMA-aware IA-64 systems. Some applications might require a larger heap, and
especially a larger young generation, to see benefit from UseNUMA, because of the
division of eden space as described above. Use -Xmx, -Xms, and -Xmn to increase the
overall heap and young generation sizes, respectively. There are some applications
that ultimately do not benefit because of their heap-usage patterns.
Specifying UseNUMA also enables UseLargePages by default. UseLargePages can
have the side effect of consuming more address space, because of the stronger alignment
of memory regions. This means that in environments where memory is tight but a large
Java heap is specified, UseLargePages might require the heap size to be reduced, or
Java will fail to start up. If this occurs when UseNUMA is specified, you can disable
UseLargePages on your command line and still use UseNUMA; for example:
-XX:+UseNUMA -XX:-UseLargePages.
ThreadDumpPath support
By default, sending the Java process a SIGQUIT signal results in a thread dump being
written to stdout. Starting with the JDK 6.0.06 release, the -XX:ThreadDumpPath=
<path/filename> option can be used to specify the thread dump file name or a
directory where the thread dump is created.
Garbage-First garbage collector (-XX:+UseG1GC)
The Garbage-First Garbage Collector (or G1 GC for short) is a new GC that is being
introduced in the Java HotSpot VM in JDK 7. An experimental version of G1 is included
in the 6.0.08 and later releases. G1 is the long-term replacement for HotSpot's low-latency
80 JDK/JRE 6.0.n and 7.0.n Usage Notes