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

[Roman Kennke]

Am 31.01.2018 um 21:20 schrieb Aleksey Shipilev:
> On 01/31/2018 09:19 PM, Aleksey Shipilev wrote:
>> 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
> 
> I like the ShenandoahAllocImplicitLive flag better, because it avoids the v-call to
> collectionPolicy() on allocation path. And it reduces coupling between components.
> 
> -Aleksey
> 
> 
> 

Ok. Then this:

http://cr.openjdk.java.net/~rkennke/better-traversal-heuristics/webrev.03

?

Roman