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

[Zhengyu Gu]

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