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

[Ashutosh Mehra]

On Tue, 20 Sep 2022 21:00:26 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> `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.

Thanks for pointing out that bug. It explains the need for the keep_alive API. But that API is solving a different issue than what we are facing here. I think we are on right track with respect to adding LRB during object iteration.

I am going to try changing `ObjectIterateScanRootClosure` to use `HeapAccess<AS_NO_KEEPALIVE>` instead of `RawAccess`.
I have been deliberating over the need for `if (_heap->is_concurrent_weak_root_in_progress() && !_marking_context->is_marked(obj))` check in `ObjectIterateScanRootClosure` after we switch to HeapAccess. The same check is executed by LRB [1] if `ON_PHANTOM_OOP_REF` decorator is also set, which makes me think we should probably use `HeapAccess<AS_NO_KEEPALIVE | ON_PHANTOM_OOP_REF>` and remove that check from `ObjectIterateScanRootClosure`. wdyt?

[1] https://github.com/openjdk/jdk/blob/6beeb8471ccf140e59864d7f983e1d9ad741309c/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp#L104-L108

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

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