RFR 8224875: Shenandoah: ParallelCleaning code unloading should take lock to protect shared code roots array

Zhengyu Gu zgu at redhat.com
Wed May 29 11:29:11 UTC 2019


On 5/28/19 12:28 PM, Aleksey Shipilev wrote:
> On 5/28/19 6:17 PM, Zhengyu Gu wrote:
>> The patch changes ShenandoahHeapLock to general purpose spin lock and uses it to protect concurrent
>> access to shared array during parallel cleaning at safepoints.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8224875
>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8224875/webrev.00/
> 
> *) Name it ShenandoahLock, maybe? The fact it is a spin lock is the implementation detail. Maybe we
> actually want to split out the rename into a separate changeset, so we can backport it ahead of time.

Okay, split into JDK-8224932


> 
> *) These two typedefs deserve to be in shenandoahHeap.hpp?
> 
>    96 typedef ShenandoahSpinLock   ShenandoahHeapLock;
>    97 typedef ShenandoahSpinLocker ShenandoahHeapLocker;

Done in JDK-8224932

> 
> *) You don't need a comment here, I think it is clear what that lock protects
> 
>   136   // Lock to protect recorded nms array
>   137   static ShenandoahSpinLock                 _recorded_nms_lock;

Okay.

> 
> *) Since you moved the assert in ShenandoahCodeRoots::remove_nmethod, is it worth it to move it in
> ShenandoahCodeRoots::add_nmethod too?
> 
Sure.

Updated webrev: http://cr.openjdk.java.net/~zgu/JDK-8224875/webrev.01/

Reran hotspot_gc_shenandoah test.

Thanks,

-Zhengyu






More information about the hotspot-gc-dev mailing list