RFR 8236880: Shenandoah: Move string dedup cleanup into concurrent phase
rkennke at redhat.com
Wed Jan 22 14:33:17 UTC 2020
Would it be possible to use scoped lockers instead in:
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