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

[Zhengyu Gu]

On Fri, 16 Sep 2022 01:33:31 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Hmm, `OopHandle::resolve` should have gone through the LRB, which should have evacuated the object. If the object is in the `cset` and it didn't get evacuated by the LRB, then it should be true that the gc is cancelled (out-of-memory during evac). Did this happen under low memory conditions? I wonder if the VM thread did _try_ to evacuate it and fail?
>
> If `OopHandle::resolve()` is hit, then the object gets evacuated through LRB, but the assertions happen before the code calls `resolve`.
> The assertion `assert_not_in_cset` is hit when `OopHandle` is created (see frame 16 in the stack trace mentioned [here](https://github.com/openjdk/jdk/pull/10268#issuecomment-1247282078))
> The new assertion that I mentioned in previous comment also happens before the `OopHandle` is resolved.

> The collection set is chosen during final mark and should always be empty during concurrent mark, so restricting this assertion to run only when concurrent mark is in progress effectively disables it.

I believe it is true for satb mode, but not true for iu mode: iu mode has cset during concurrent marking.

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

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