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

Zhengyu Gu zgu at openjdk.java.net
Mon Oct 11 12:23:11 UTC 2021


On Mon, 11 Oct 2021 10:46:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Hold on a sec, I have questions...
> 
> I see `MultiArray_lock` is `safepoint`. Shouldn't this be `safepoint - 1` then? 
You see any difference with safepoint-1 and safepoint-2?  

I do agree probably should be safepoint-1 because https://github.com/openjdk/jdk/pull/5869 did that.

I think this would basically say "you can acquire any `safepoint` lock", right? Also, does the same thing apply to `_gc_waiters_lock`?
> 
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.

> Changing both locks to `safepoint - 1` passes `hotspot_gc_shenandoah` for me here.

I will make change on _alloc_failure_waiters_lock rank, but not sure we really need to change _gc_waiters_lock, what your opinion?

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

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


More information about the shenandoah-dev mailing list