RFR: Non-cancellable mark loops should have sensible stride

Roman Kennke rkennke at redhat.com
Thu Jul 5 07:38:46 UTC 2018


It looks ok. But why did we do it in the first place? It looks like this
was done on purpose. But it also seems illogical. Can you hg annotate it
and see how that happened?

Roman


> Both final-mark and mark-compact are affected by this: we set the stride to 1 for non-cancellable
> loops, but that is inconvenient for better pipelining and prefetching work. This also makes Full GC
> mark and concurrent mark subtly different performance-wise, which complicates performance testing.
> We should still do strides for non-cancellable loops too!
> 
> diff -r 4f5549ec27fb src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp
> --- a/src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp	Wed Jul 04 11:57:32 2018 +0200
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp	Thu Jul 05 09:21:55 2018 +0200
> @@ -937,7 +937,7 @@
>  template <class T, bool CANCELLABLE>
>  void ShenandoahConcurrentMark::mark_loop_work(T* cl, jushort* live_data, uint worker_id,
> ParallelTaskTerminator *terminator) {
>    int seed = 17;
> -  uintx stride = CANCELLABLE ? ShenandoahMarkLoopStride : 1;
> +  uintx stride = ShenandoahMarkLoopStride;
> 
>    ShenandoahHeap* heap = ShenandoahHeap::heap();
>    ShenandoahObjToScanQueueSet* queues = task_queues();
> 
> Testing: tier1_gc_shenandoah, benchmarks
> 
> Thanks,
> -Aleksey
> 




More information about the shenandoah-dev mailing list