RFR: Avoid indirection to next-mark-context
Roman Kennke
rkennke at redhat.com
Tue Jul 17 21:13:49 UTC 2018
Am 17.07.2018 um 22:53 schrieb Aleksey Shipilev:
> On 07/17/2018 10:26 PM, Roman Kennke wrote:
>> On top of the ShenandoahMarkingContext patch, this change avoids the
>> extra indirection that we always need to take in hot marking path to get
>> to the next-mark-bitmap and next-TAMS-structures. It does so by picking
>> the next-marking-context at the beginning of the phase, and then keep it
>> around in the closure.
>>
>> Testing: tier3_gc_shenandoah ok
>>
>> http://cr.openjdk.java.net/~rkennke/direct-marking/webrev.00/
>
> Looks good. Does it actually help marking performance?
My little bit of perf testing was inconclusive. If it helps, then not by
much. I think the marking/traversal loops are drowned by fwd ptr
reads+stalls.
Will fix the rest and RFR tomorrow.
Cheers,
Roman
> Stylistic:
>
> *) It seems odd that in these blocks two class members are on the same line:
>
> 65 ShenandoahInitMarkRootsClosure(ShenandoahObjToScanQueue* q) :
> 66 _queue(q), _heap(ShenandoahHeap::heap()),
> 67 _mark_context(_heap->next_marking_context()) {};
>
> ...but here, they are split:
>
>
> 73 ShenandoahMarkRefsSuperClosure::ShenandoahMarkRefsSuperClosure(...) :
> 74 MetadataVisitingOopIterateClosure(rp),
> 75 _queue(q),
> 76 _heap(ShenandoahHeap::heap()),
> 77 _mark_context(_heap->next_marking_context())
> 78 { }
>
> Pick a style and stick to it?
>
> Thanks,
> -Aleksey
>
More information about the shenandoah-dev
mailing list