JDK-5086424 : improve the performance of GC_locker
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2004-08-12
  • Updated: 2012-10-13
  • Resolved: 2004-09-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other JDK 6
1.3.1_17Fixed 1.4.2_09Fixed 6 mustangFixed
Related Reports
Relates :  
JDK-6354914 - snv_27a 3.71% XML performance regression (SPARC)
Description
Currently GC_locker is centered around JNICritical_lock which is expensive,
especially when it's under contention. Need to find a way to improve the
performance by not grabbing JNICritical_lock in common cases.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang FIXED IN: mustang INTEGRATED IN: mustang
15-09-2004
PUBLIC COMMENTS Integrated in Build 04
15-09-2004
EVALUATION - Factor GC_locker::lock_critical and GC_locker::unlock_critical into fast path and slow path. The fast path isn't protected by JNICritical_lock. jni_lock() and jni_unlock() are changed to be atomic operations. - Nested cases are optimized so no jni_lock()/jni_unlock() are done. - Instead of being set during heap expansion, GC_locker::_needs_gc is set when a GC attempt is aborted because GC_locker is active. _needs_gc is also only set at a safepoint. - A GC_locker::_doing_gc is added to prevent starvation from happening when MutexUnlocker in unlock_critical() drops JNICritical_lock and can be grabbed by lock_critical() immediately. ###@###.### 2004-09-02
02-09-2004