RFR: 8317440: Lock rank checking fails when code root set is modified with the Servicelock held after JDK-8315503

[Thomas Schatzl]

On Fri, 6 Oct 2023 11:49:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that fixes lock ranking after recent changes to the code root set, now using a CHT.
>> 
>> The issue came up because the lock rank of the CHT lock has been larger than the rank of the Servicethread_lock where it is possible that code roots can be added.
>> 
>> The suggested solution is to fix up the lock rankings to work; actually this PR contains two variants:
>> 1) one that statically sets the lock ranks of the CHT lock (and the ThreadSMR_lock that can be used during CHT operation) to something smaller than Servicethread_lock.
>> 2) one that allows setting of the CHT lock rank via parameter as well (the last commit changed the code to variant 1).
>> 
>> The other lock ranking changes to Metaspace_lock and ContinuationRelativize_lock are simply undos of the respective changes in [JDK-8315503](https://bugs.openjdk.org/browse/JDK-8315503). 
>> 
>> Testing: tier1-8 for variant 2), tier 1-7 for variant 1)
>> 
>> Thanks,
>>   Thomas
>
> Variant 1 seems ok. Uses of the CHT shouldn't take locks, so having a low lock ranking for CHT lock seems like it'll be fine (I can't find where it takes the ThreadsSMRDelete_lock).  If any of this breaks, we can try approach #2 next.

Thanks @coleenp @albertnetymk for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/16062#issuecomment-1752548969