| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-2220956 | 8 | Tom Rodriguez | P3 | Resolved | Fixed | b25 |
| JDK-2220866 | 7u4 | Tom Rodriguez | P3 | Closed | Fixed | b11 |
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
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
- backported by
-
JDK-2220956 JNI Get/ReleasePrimitiveArrayCritical don't scale
-
- Resolved
-
-
-
- Closed
-
- relates to
-
JDK-7150390 JFR test crashed on assert(_jni_lock_count == count) failed: must be equal
-
- Closed
-
-
-
- Open
-