RFR: Don't treat allocation regions implicitely live during traversal GC
Aleksey Shipilev
shade at redhat.com
Wed Jan 31 20:20:39 UTC 2018
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
More information about the shenandoah-dev
mailing list