-
Bug
-
Resolution: Fixed
-
P2
-
8, 11, 14
-
b27
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8263724 | 11.0.12-oracle | Dukebot | P2 | Closed | Fixed | b01 |
JDK-8261318 | 11.0.11 | Stefan Karlsson | P2 | Resolved | Fixed | b02 |
- Return non-reachable objects - for example, when G1 walks the prev bitmap
- Return the Reference.referent without an appropriate resurrection barrier
- Return an object loaded without a "strong"/"marking" barrier
These objects should not escape the confines of the active safepoint that calls object_iterate. If they do we run the risk of various crashes when the objects get garbage collected.
Unfortunately, there are a few closures that do this. The once we have identified are:
- HeapInspection::find_instances_at_safepoint
- JVMTI object tagging
There might be some merit to solving this by altering the object_iterate API, but for now we'd like to fix the two problematic areas listed above. The suggestion is to introduce a CollectedHeap::keep_alive function that notifies the GC that the object should be kept alive the current GC cycle (if active).
- backported by
-
JDK-8261318 Dying objects are published from users of CollectedHeap::object_iterate
- Resolved
-
JDK-8263724 Dying objects are published from users of CollectedHeap::object_iterate
- Closed
- blocks
-
JDK-8234508 VM_HeapWalkOperation::iterate_over_object reads non-strong fields with an on-strong load barrier
- Resolved
- duplicates
-
JDK-8233434 ZGC: ZHeapIterator ran into something dead
- Closed
- relates to
-
JDK-8235305 Corrupted oops embedded in nmethods due to parallel modification during optional evacuation
- Closed
-
JDK-8237369 Shenandoah: failed vmTestbase/nsk/jvmti/AttachOnDemand/attach021/TestDescription.java test
- Resolved