RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash with IU+aggressive mode

William Kemper wkemper at openjdk.org
Tue Sep 20 21:02:43 UTC 2022


On Fri, 16 Sep 2022 21:34:47 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Thanks for clarifying that.
>> 
>> For option 1, I don't see any access API that acts on oop directly. Is there any? 
>> Would it better to evacuate the oops explicitly in `ObjectIterateScanRootClosure` before handing out the oop to `FindInstanceClosure` in heapInspection.cpp.
>
> `ObjectIterateScanRootClosure` should probably use `NativeAccess<AS_NO_KEEPALIVE>::oop_load` (or `HeapAccess`) rather than `RawAccess<>::oop_load(p);` (which bypasses the LRB).

This looks related: https://bugs.openjdk.org/browse/JDK-8235324. The `CollectedHeap::keep_alive` API doesn't support the case where the given oop would need to be evacuated and return the new location.

-------------

PR: https://git.openjdk.org/jdk/pull/10268



More information about the hotspot-gc-dev mailing list