United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 5086424 improve the performance of GC_locker
5086424 : improve the performance of GC_locker

Details
Type:
Enhancement
Submit Date:
2004-08-12
Status:
Closed
Updated Date:
2012-10-13
Project Name:
JDK
Resolved Date:
2004-09-14
Component:
hotspot
OS:
generic
Sub-Component:
runtime
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:
6

Related Reports
Backport:
JDK-2125531 - improve the performance of GC_locker
Backport:
JDK-2125534 - improve the performance of GC_locker
Backport:
JDK-2128167 - improve the performance of GC_locker
Relates:
JDK-6354914 - snv_27a 3.71% XML performance regression (SPARC)

Sub Tasks

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
PUBLIC COMMENTS

Integrated in Build 04
2004-09-15 
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mustang

FIXED IN:
mustang

INTEGRATED IN:
mustang
2004-09-15 
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
2004-09-02


Hardware and Software, Engineered to Work Together