RFR: 8274925: Shenandoah: shenandoah/TestAllocHumongousFragment.java test failed on lock rank check

[Aleksey Shipilev]

On Fri, 8 Oct 2021 13:40:51 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> JDK-8273917 lowered MultiArray_lock rank from nonleaf+2 to nonleaf, that results several Shenandoah tests failed on lock rank check.
> 
> This patch lowers ShenandoahAllocFailureGC_lock rank by 2 to maintain original order.
> 
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah

> I do agree probably should be safepoint-1 because #5869 did that.

Yes, I think Shenandoah never takes `JNICritical_lock`, so it is fine to have `safepoint - 1` here.

> I thought about that. It appears that _gc_waiters_lock is only acquired vs. SH::collect(), where I don't see it is possible holding MultiArray_lock.

I think it is technically possible to call `SH::collect()` from the Java code that holds the `MultiArray_lock`, as part of OOM allocation? I think it would be future-proof to accept all `safepoint`-rank locks in `ShenandoahControlThread`, i.e. make all of them `safepoint - 1`. You probably want to run `tier1`, `tier2` with `TEST_VM_OPTS=-XX:+UseShenandoahGC` to confirm.

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

PR: https://git.openjdk.java.net/jdk/pull/5865