RFR: Optimizing best of two work stealing queue selection

Thomas Schatzl thomas.schatzl at oracle.com
Wed Jun 27 12:04:37 UTC 2018


Hi,

On Mon, 2018-06-25 at 09:09 -0400, Zhengyu Gu wrote:
> Hi,
> 
> I did a few runs of Compiler.sunflow benchmark over past weekend,
> with different task terminators and best-of-2 queue selection
> algorithms. One  factor that is not reflected in the flags, 
> ShenandoahParallelClaimableQueueSet, that I believe to have impact
> on termination.
> 
> It looks like that the optimization always has positive impact, and
> the results were pretty consistent. Does the result convincing enough
> for purposing upstream?
> 

:) To me, yes.

Note that this change may not only improve task termination but also
evacuation in general as the code only goes into the termination
protocol if it can't steal. So the numbers you present here do not
necessarily show the whole picture.

I managed to do a few tests on known-changes sensitive benchmarks I
typically use, but the worst result I had was that pause times did not
budge at all (specjbb2005); but I also got nice significant average
pause time decrease in some cases (for the [2] patch, e.g. on
BigRamTester [5]).

When trying to reproduce the results in the paper I was not able to
reproduce them for either lusearch or sunflow which seemed to show the
best improvements.
Parallel seems to fare better at least from the numbers the change
prints, but I have not seen any impact on pause times or throughput as
the paper shows.
(Otoh pause times range in the few ms there anyway; mostly referring to
figure 10a here)

My runs were with

-Xmx<heapsize> -Xms<heapsize> -XX:ParallelGCThreads=10 -XX:+<collector>
-jar dacapo-9.12-bach.jar -n 20 <benchmark>

and threads and cpu bound to a single node on almost the same processor
as in the paper; jdk11 tip.

Currently preparing a build for our perf regression suite, but running
that will take some time.

I would however prefer if the change incorporated the earlier
suggestions made in this thread before upstreaming; I would probably
ask about them anyway. ;)

> * Shenandoah Repo with patch [1]:
>                                            ShenandoahGC
>                                          Avg.      Worst
> +ShenandoahOWST/+OptimizedBestOfTwo     0.145      16
> +ShenandoahOWST/-OptimizedBestOfTwo     1.552      269
> -ShenandoahOWST/+OptimizedBestOfTwo     0.341      52
> -ShenandoahOWST/-OptimizedBestofTwo     2.327      384
> 
>                                G1
>                         Avg.       Worst
> +OptimizedBestOfTwo    23.049     335
> -OptimizedBestOfTwo    43.632     930
> 
> 
> 
> * JDK repo with patch [2]
>                                G1
>                         Avg.       Worst
> +OptimizedBestOfTwo    17.496     469
> -OptimizedBestOfTwo    26.670     1062
> 
> 
> [3] and [4] are full logs.
> 
> Thanks,
> 
> -Zhengyu
> 
> 
> [1] http://cr.openjdk.java.net/~zgu/tq_terminator/shenandoah.patch
> [2] http://cr.openjdk.java.net/~zgu/tq_terminator/jdk.patch
> [3] http://cr.openjdk.java.net/~zgu/tq_terminator/shenandoah.log
> [4] http://cr.openjdk.java.net/~zgu/tq_terminator/jdk.log

Thomas

[5] https://bugs.openjdk.java.net/browse/JDK-8152438


More information about the shenandoah-dev mailing list