United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7129164 JNI Get/ReleasePrimitiveArrayCritical don't scale
JDK-7129164 : JNI Get/ReleasePrimitiveArrayCritical don't scale

Details
Type:
Enhancement
Submit Date:
2012-01-11
Status:
Resolved
Updated Date:
2012-03-22
Project Name:
JDK
Resolved Date:
2012-02-07
Component:
hotspot
OS:
generic
Sub-Component:
gc
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs23
Fixed Versions:
hs23 (b13)

Related Reports
Backport:
Backport:
Relates:

Sub Tasks

Description
JNI critical methods in Hotspot (such as GetPrimitiveArrayCritical, ReleasePrimitvieArrayCritical and so on) contain Atomic methods (inc, dec)
to update shared variable _jni_lock_count. In case of frequent calls to these
methods we observe true sharing problem. The attached draft patch skips
grabbing the jni lock (and thus updating _jni_lock_count) unless a gc is
needed and the thread isn't already in a critical section.

See the preliminary results for a simple micro benchmarks in attach that check
scalability on WSM EP (RHEL 5.5, V7B147):

Threads                       1         12       24

Default hotspot             7244       9504    17540

Patched hotspot             7408      81780    93819

Patched / Default           1.02       8.61     5.25

                                    

Comments
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1a2723f7ad8e
                                     
2012-01-30
EVALUATION

7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale
Summary:
Reviewed-by:

The machinery for GC_locker which supports GetPrimitiveArrayCritical
maintains a count of the number of threads that currently have raw
pointers exposed.  This is used to allow existing critical sections to
drain before creating new ones so that a GC can occur.  Currently
these counts are updated using atomic all the time, even if a GC isn't
being requested.  This creates scalability problem when a lot of
threads are hammering atomic operations on the jni_lock_count.  The
count only needs to be valid when checking if a critical section is
currently active and when draining the existing sections.  The fix is
to make the count be computed as part of the safepointing machinery
and to only decrement the counters when _needs_gc is true.  In debug
mode the old count is maintained and validated against the lazily
computed count.

On a microbenchmark that stresses GetPrimitiveArrayCritical with many
threads and relatively short critical section it can more than double
the throughput.  This also slightly speeds up the normal
GetPrimtiveArrayCritical calls.  Mostly it's not easily measurable
with larger scale programs.

Tested with microbenchmark that stresses GetPrimtiveArrayCritical and
the crypto benchmarks of specjvm2008 on x86 and sparc.  I also ran the
java.io regression tests from the JDK.
                                     
2012-02-06
EVALUATION

http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1a2723f7ad8e
                                     
2012-03-22



Hardware and Software, Engineered to Work Together