Caution needs to be taken when CollectedHeap::object_iterate is used. It may:
- 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).
- 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).
- 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
-