RFR: Don't treat allocation regions implicitely live during traversal GC

Aleksey Shipilev shade at redhat.com
Wed Jan 31 20:15:10 UTC 2018


On 01/31/2018 09:03 PM, Aleksey Shipilev wrote:
> On 01/31/2018 08:59 PM, Roman Kennke wrote:
>> Until now, we treated allocation regions from between GC cycles all live in traversal GC. This seems
>> inconsequential: we are not treating alloc regions live during the cycle. This means that all the
>> allocated garbage will have to pass through one complete cycle to count its liveness, and then
>> another cycle to clear it up. This patch changes this to traverse+clear alloc regions in the next
>> cycle.
>>
>> This gives some application a huge boost. E.g. compiler.compiler goes from 180ops/m to around
>> 205ops/m in my tests.
>>
>> http://cr.openjdk.java.net/~rkennke/better-traversal-heuristics/webrev.00/
> 
> Um. Doesn't it break non-Traversal GCs? Shared/TLAB allocs would not be counted as live with e.g.
> "adaptive"?

Yes, it does break half of hotspot_gc_shenandoah. Should be e.g.:

bool ShenandoahFreeSet::implicit_live(ShenandoahHeap::AllocType type) const {
  ShenandoahHeap* heap = ShenandoahHeap::heap();
  if (heap->shenandoahPolicy()->can_do_traversal_gc()) {
    if (heap->is_concurrent_traversal_in_progress()) {
      return false;
    }
    switch (type) {
      case ShenandoahHeap::_alloc_tlab:
      case ShenandoahHeap::_alloc_shared:
        return false;
      case ShenandoahHeap::_alloc_gclab:
      case ShenandoahHeap::_alloc_shared_gc:
        return true;
      default:
        ShouldNotReachHere();
    }
  }
  return true;
}

-Aleksey



More information about the shenandoah-dev mailing list