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

[Roman Kennke]

Hi Zhengyu,

>> 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.

Hmmhmm. Ok then.

Roman


> 
> -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
>>>
>>
>