EasyManua.ls Logo

IBM Power7 - Java Lock Reservation; Java GC Threads

IBM Power7
224 pages
To Next Page IconTo Next Page
To Next Page IconTo Next Page
To Previous Page IconTo Previous Page
To Previous Page IconTo Previous Page
Loading...
Chapter 7. Java 135
To achieve the best performance with RSETs that are created across multiple cores, all cores
of the RSET must be from the same chip and in the same scheduler resource allocation
domain (SRAD). The lssrad command can be used to determine which logical CPUs belong
to which SRAD, as shown in Example 7-2:
Example 7-2 Use the lssrad command to determine which logical CPUs belong to which SRAD
# lssrad -av
REF1 SRAD MEM CPU
0
0 22397.25 0-31
1
1 29801.75 32-63
The output in Example 7-2 shows a system that has two SRADs. CPUs 0 - 31 belong to the
first SRAD, and CPUs 32 - 63 belong to the second SRAD. In this example, create an RSET
with multiple cores either using the CPUs of the first or second SRAD.
7.5.3 Java lock reservation
Synchronization and locking are an important part of any multi-threaded application. Shared
resources must be adequately protected by monitors to ensure correctness, even if some
resources are only infrequently shared. If a resource is primarily accessed by a single thread
at any time, that thread is frequently the only thread to acquire the monitor that is guarding the
resource. In such cases, the cost of acquiring the monitor can be reduced by using the
-XlockReservation option. With this option, it is assumed that the last thread to acquire the
monitor is also likely to be the next thread to acquire it. The lock is, therefore, said to be
reserved for that thread, minimizing its cost to acquire and release the monitor. This option is
suited to workloads using many threads and many shared resources that are infrequently
shared in practice.
7.5.4 Java GC threads
The GC used by the JVM takes every opportunity to use parallelism on multi-CPU machines.
All phases of the GC can be run in parallel with multiple helper threads dividing up the work to
complete the task as quickly as possible. Depending on the GC strategy and heap size in use,
it can be beneficial to adjust the number of threads that the GC uses. The number of GC
threads can be specified with the -Xgcthreads<
number> option. The default number of GC
threads is generally equal to the number of logical processors on the partition, and it is
usually not helpful to exceed this value. Reducing it, however, reduces the GC impact and
might be wanted in some situations, such as when RSETs are used. The number of GC
threads is capped at 64 starting in V2.6 J9 VM.
Authority for RSETs: A user must have root authority or have CAP_NUMA_ATTACH capability
to use RSETs.

Table of Contents

Related product manuals