RFR 8236880: Shenandoah: Move string dedup cleanup into concurrent phase
zgu at redhat.com
Wed Jan 22 14:37:12 UTC 2020
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:
They are conditional and somewhat already scoped, e.g. lock in
constructor and unlock i destructor.
> The rest looks ok to me.
>> 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/
>> hotspot_gc_shenandoah with -XX:+UseStringDeduplication
>> (fastdebug and release) on x86_64 and aarch64 Linux
More information about the hotspot-gc-dev