RFR: Avoid indirection to next-mark-context

Roman Kennke rkennke at redhat.com
Thu Jul 19 09:20:35 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?
> 
> 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 now?
Roman



More information about the shenandoah-dev mailing list