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