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

[Ashutosh Mehra]

On Fri, 16 Sep 2022 20:30:45 GMT, William Kemper <wkemper at openjdk.org> wrote:

>>> The assert happens when the heap inspection tries to create a pointer to an object in the collection set that was visited during this heap walk
>> 
>> That's right.
>> I am inclined towards option 1 as it should (theoretically speaking) solve the other assertion failure as well.
>> 
>>> Option 1. is probably the Right Thing to do, but I'm no sure what would happen if the VMThread is unable to find memory for the evacuated object.
>> 
>> Can you please help me understand if we add LRB during heap inspection, why would VMThread ever be in situation where it fails to find memory for the evacuated object?
>
> I just meant it could suffer from an out-of-memory error just like any other evacuating thread, but I think it'd be fine. The LRB would cancel the GC and the from-space reference would be returned (cancelling the GC would nullify the assert). If the from-space reference is still reachable after the thread dump completes, the degenerated cycle should fix it up.

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.

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

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