RFR: Avoid indirection to next-mark-context

Aleksey Shipilev shade at redhat.com
Thu Jul 19 09:21:28 UTC 2018


On 07/19/2018 11:20 AM, Roman Kennke wrote:
> 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?
>>
>> 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?
> 
> Right. Let's put each member on a new line.
> 
> Incremental:
> http://cr.openjdk.java.net/~rkennke/direct-marking/webrev.01.diff/
> Full:
> http://cr.openjdk.java.net/~rkennke/direct-marking/webrev.01/

OK.

-Aleksey




More information about the shenandoah-dev mailing list