RFR: Traversal evac assist should poll "next" marking context
Aleksey Shipilev
shade at redhat.com
Tue Aug 14 11:31:53 UTC 2018
This fixes the actual bug with evac assists and Traversal. It needs to poll the other context,
otherwise it evacuates unnecessary objects on assist path:
diff -r ad159fcdf3be src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
--- a/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp Tue Aug 14 13:13:39 2018 +0200
+++ b/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp Tue Aug 14 13:28:35 2018 +0200
@@ -286,11 +286,15 @@
// total assist costs, and can introduce a lot of evacuation latency. This is why we
// only scan for _nearest_ N objects, regardless if they are eligible for evac or not.
size_t max = ShenandoahEvacAssist;
if (max > 0) {
- ShenandoahMarkingContext* ctx = _heap->complete_marking_context();
+ // Traversal is special: it uses "next" marking context, because it coalesces evac with mark.
+ // Other code uses "complete" marking, because evac happens after the mark.
+ ShenandoahMarkingContext* ctx = _heap->is_concurrent_traversal_in_progress() ?
+ _heap->next_marking_context() : _heap->complete_marking_context();
+
ShenandoahHeapRegion* r = _heap->heap_region_containing(obj);
assert(r->is_cset(), "sanity");
HeapWord* cur = (HeapWord*)obj + obj->size() + BrooksPointer::word_size();
size_t count = 0;
Testing: tier1_gc_shenandoah, benchmarks with evac stats
Thanks,
-Aleksey
More information about the shenandoah-dev
mailing list