-
Bug
-
Resolution: Fixed
-
P4
-
11, 17, 20, 21
-
b18
-
aarch32
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8305996 | 17.0.8 | Thomas Stuefe | P4 | Resolved | Fixed | b01 |
| JDK-8306064 | 11.0.20 | Thomas Stuefe | P4 | Resolved | Fixed | b01 |
Due to a small bug in the C2 implementation of monitorexit for stacklocked locks, we always enter slow path.
AFAICS This is a day zero bug of the arm port and got introduced with JEP 297: "Unified arm32/arm64 Port".
It has a significant effect on locking performance, but its effect had been hidden until JDK15 by biased locking. Biased locking removal made the bug appearant.
AFAICS This is a day zero bug of the arm port and got introduced with JEP 297: "Unified arm32/arm64 Port".
It has a significant effect on locking performance, but its effect had been hidden until JDK15 by biased locking. Biased locking removal made the bug appearant.
- backported by
-
JDK-8305996 Arm: C2 always enters slowpath for monitorexit
-
- Resolved
-
-
-
- Resolved
-
- links to
-
Commit
openjdk/jdk11u-dev/f0af8f99
-
Commit
openjdk/jdk17u-dev/01cf112c
-
Commit
openjdk/jdk/c67bbcea
-
Review
openjdk/jdk11u-dev/1826
-
Review
openjdk/jdk17u-dev/1237
-
Review
openjdk/jdk/13376
(3 links to)