-
Bug
-
Resolution: Fixed
-
P3
-
16-pool, 17-pool, 18
-
b22
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8277683 | 17.0.3-oracle | Zhengyu Gu | P3 | Resolved | Fixed | b01 |
JDK-8277339 | 17.0.2 | Zhengyu Gu | P3 | Resolved | Fixed | b06 |
Before concurrent GC, CodeCache_lock is not required for walking CodeCache at safepoints. But it is not the case for Shenandoah, as code cache iteration can be initialized and run through safepoints.
To initialize concurrent code cache iteration, CodeCache_lock is required, even at safepoints, as the lock is acquired without safepoint check.
There are few bugs in current implementation:
1) No CodeCache_lock is held when initialize code cache iterator at safepoints.
2) Does not notify waiters upon completion of iteration at safepoints
3) Unnecessary held CodeCache_lock during concurrent code cache iteration.
To initialize concurrent code cache iteration, CodeCache_lock is required, even at safepoints, as the lock is acquired without safepoint check.
There are few bugs in current implementation:
1) No CodeCache_lock is held when initialize code cache iterator at safepoints.
2) Does not notify waiters upon completion of iteration at safepoints
3) Unnecessary held CodeCache_lock during concurrent code cache iteration.
- backported by
-
JDK-8277339 Shenandoah: CodeCache_lock should always be held for initializing code cache iteration
-
- Resolved
-
-
JDK-8277683 Shenandoah: CodeCache_lock should always be held for initializing code cache iteration
-
- Resolved
-
- relates to
-
JDK-8276801 gc/stress/CriticalNativeStress.java fails intermittently with Shenandoah
-
- Resolved
-
- links to
-
Commit openjdk/jdk17u/f1a8a22f
-
Commit openjdk/jdk/99b7b95e
-
Review openjdk/jdk17u/262
-
Review openjdk/jdk/6192
(2 links to)