HP-UX Programmer's Guide for Java 2

Table Of Contents
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