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