JDK-5086424 : improve the performance of GC_locker
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.
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.
BugTraq+ Release Management Values
COMMIT TO FIX:
Integrated in Build 04
- 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.