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

[Aleksey Shipilev]

On 01/31/2018 09:15 PM, Roman Kennke wrote:
> Am 31.01.2018 um 21:03 schrieb Aleksey Shipilev:
>> 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"?
>>
> 
> Grr. See this is what happens when you want to rush out a change when brain is pudding ;-) In my
> tests I guarded this by UseNewCode...
> 
> http://cr.openjdk.java.net/~rkennke/better-traversal-heuristics/webrev.01/
> 
> Better?

Yes, that seems okay. I'd still suggest a switch to guard from accidental enums:

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

-Aleksey