-
Type:
Bug
-
Resolution: Fixed
-
Priority:
P3
-
Affects Version/s: 9
-
Component/s: hotspot
-
b159
-
generic
-
generic
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8176678 | 10 | Sangheon Kim | P3 | Resolved | Fixed | b03 |
| JDK-8208888 | 8u201 | Sangheon Kim | P3 | Resolved | Fixed | b01 |
| JDK-8201583 | 8u192 | Sangheon Kim | P3 | Resolved | Fixed | b01 |
| JDK-8216708 | emb-8u201 | Sangheon Kim | P3 | Resolved | Fixed | master |
JvmtiTagHashmapEntry has a bare oop member. These are weak references. Any place that allows that oop to "escape" needs the G1 pre-barrier.
GetObjectsWithTags provides such an escape path. All other accesses to that oop appear to be "peek" operations, where the oop is locally examined without any possibility of a safepoint while it's being used. Without that barrier, use of this JVMTI function with G1 can lead to crashes.
GetObjectsWithTags provides such an escape path. All other accesses to that oop appear to be "peek" operations, where the oop is locally examined without any possibility of a safepoint while it's being used. Without that barrier, use of this JVMTI function with G1 can lead to crashes.
- backported by
-
JDK-8176678 JVMTI tagged object access needs G1 pre-barrier
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
- relates to
-
-
- Closed
-