[15] RFR 8236880: Shenandoah: Move string dedup cleanup into concurrent phase

[Zhengyu Gu]

Hi Roman,

Thanks for the review.

On 1/22/20 9:33 AM, Roman Kennke wrote:
> Hi Zhengyu,
> 
> Would it be possible to use scoped lockers instead in:
> 
> src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp
> 

They are conditional and somewhat already scoped, e.g. lock in 
constructor and unlock i destructor.

-Zhengyu

> The rest looks ok to me.
> 
> Thanks,
> Roman
> 
>> Please review this patch that moves string deduplication cleanup task
>> into concurrent phase.
>>
>> The cleanup task composites two subtasks: StringDedupTable and
>> StringDedupQueue cleanup.
>>
>> Concurrent StringDedupTable cleanup is very straightforward. GC takes
>> StringDedupTable_lock to block out mutators from modifying the table,
>> then performs multi-thread cleanup, just as it does at STW pause.
>>
>> Concurrent StringDedupQueue cleanup is more complicated. GC takes
>> StringDedupQueue_lock, only blocks queue structure changes, while
>> mutators can still enqueue new string candidates and dedup thread can
>> still perform deduplication. So there are a couple of synchronizations
>> need to be established.
>>
>> 1) When mutator enqueues a candidate, the enqueued oop should be valid
>> before the slot can be made visible to GC threads.
>>
>> 2) When GC thread updates oop, it needs to make sure that dedup thread
>> does not see partially updated oop.
>>
>> The implementation uses load_acquire/release_store pair to ensure above
>> synchronization held.
>>
>> GC threads may miss some just enqueued oops by mutators. This is not a
>> concern, since LRB guarantees they are in to-space.
>>
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236880
>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8236880/webrev.00/
>>
>>
>> Test:
>>    hotspot_gc_shenandoah with -XX:+UseStringDeduplication
>>    (fastdebug and release) on x86_64 and aarch64 Linux
>>
>> Thanks,
>>
>> -Zhengyu
>>
>