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

[Roman Kennke]

Hi Zhengyu,

Would it be possible to use scoped lockers instead in:

src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp

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
>