RFR 8227104: Shenandoah: Implementation of ShenandoahReentrantLock

[Zhengyu Gu]

On 7/2/19 2:11 PM, Roman Kennke wrote:
> Why would we want to backport the ShenandoahReentrantLock if it has no
> uses? 

We might want to backport ShenandoahNMethod stuff, not 
ShenandoahReentrantLock.


Or will we have uses that we intend to backport? Not quite sure
> here why we would want to push any code that's not currently used, and
> not push the code plus its usage instead.

That changeset can grow really big if we don't split it up. To make it 
work, it needs nmethod barrier, concurrent nmethod iteration, reentrant 
lock and etc. all in place. Which approach you prefer?

Thanks,

-Zhengyu

> 
> Roman
> 
> 
>> This is a prerequisite for concurrent nmethod unloading [1]. Currently,
>> it has no users, but will be embedded into ShenandoahNMethod.
>>
>> I separate the two changes, in case we may want to backport
>> ShenandoahNMethod changes.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227104
>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8227104/webrev.00/
>>
>> Test:
>>    fastdebug and release builds.
>>
>> Thanks,
>>
>> -Zhengyu
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8227102
>