Re: ForkJoin refresh

Thanks Doug - how different is this to the Java 14-EA version?  I 
noticed the ManagedBlocker implementation today whilst showing the 
Condition.await() implementation to a class I was teaching and even 
tweeted about it: https://twitter.com/heinzkabutz/status/1218204292626243585

Funny coincidence :-)

Regards

Heinz
-- 
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java™ Specialists' Newsletter" - www.javaspecialists.eu
Java Champion - www.javachampions.org
JavaOne Rock Star Speaker
Tel: +30 69 75 595 262
Skype: kabutz

On 2020/01/17 16:39, Doug Lea via Concurrency-interest wrote:
> Now committed in jsr166 are extensions of the AQS refresh of last fall
> to also cover ForkJoin; among other things removing reliance on builtin
> monitors  The extra few months were mainly a result of noticing that the
> initial way I did this increased performance differences across garbage
> collectors. These are now reduced (not increased), but still worth
> noting: FJ programs are relatively sensitive to GC choice because they
> entail work-stealing duels between program and collector. On hotspot,
> usually the best throughput for divide-and-conquer style usages
> (including parallelStreams) is with -XX:+UseParallelGC. For unstructured
> computations with lots of little tasks (for example little
> CompletableFutures), UseShenandoahGC (and/or if needing more than 32GB
> heap, UseZGC) are often better choices.  UseParallelGC meshes well with
> highly generational structured parallelism, but is prone to
> card-mark-contention with small tasks (even with -XX:+UseCondCardMark)
> and long pauses. The default UseG1GC tends to be somewhere in the
> middle. Also, on linux, using -XX:+UseTransparentHugePages seems to
> always be a good idea for programs using FJ. (Other switches seem to
> have less consistent positive effects.)
>
> These days, it is almost impossible to quantify exactly how much better
> performance is, but it's likely that your usages are faster. For
> example, about half of the programs in the recent Renaissance Suite
> (https://renaissance.dev/) somehow use FJ, and most of these have
> improved scores on most machines, most JVMs (including OpenJ9 and
> Graal), most collectors, most phases of the moon....
>
> It would be great to get feedback from other usages before integrating
> into OpenJDK. As usual, you can try it with any JDK11+ JVM by grabbing
> http://gee.cs.oswego.edu/dl/concurrent/dist/jsr166.jar and running "java
> --patch-module java.base="$DIR/jsr166.jar", where DIR is the full file
> prefix. (Although beware that using --patch-module slows down startup,
> and occasionally entire test runs. For other options, see
> http://gee.cs.oswego.edu/dl/concurrency-interest/index.html).
>
> -Doug
>
> _______________________________________________
> Concurrency-interest mailing list
> [email protected]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest