JDK-8264542 : Regression ~200% (~4x slower) in Renaissance Scrabble after JDK-8259800
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Affected Version: 17
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86_64
  • Submitted: 2021-03-31
  • Updated: 2021-04-04
  • Resolved: 2021-04-04
Related Reports
Duplicate :  
JDK-8264572 - ForkJoinPool.getCommonPoolParallelism() reports always 1
Relates :  
JDK-8259800 - timeout in tck test testForkJoin(ForkJoinPool8Test)
Description
I see that JDK-8259800 is related to ARM but this bug is about x64 performance. We recently added several Renaissance into promo testing.

On our OCI BM2.52 platform the performance of Scrabble goes from 240ms/op to 915ms/op with this change.

Here is the repo: https://github.com/renaissance-benchmarks/renaissance/

We are running these in JMH form, it can be built by 

tools/sbt/bin/sbt clean renaissanceJmh/jmh:assembly

the JMH jar will be in renaissance-jmh/target/scala-2.12/

ls -lart renaissance-jmh-assembly-*.jar

We are running it with:
java -Djava.library.path=.  -jar renaissance-jmh-assembly-0.11.0.jar JmhScrabble -t 1 -i 15 -wi 25 -f 10
Comments
I must have mis-clicked when I closed this the first time. Re-closing as a duplicate of JDK-8264572
04-04-2021
Closing as dup of JDK-8264572
02-04-2021
JDK-8264572 is surely the problem (a copy/paste error that omitted an assignment), but isn't work-around-able even by setting property. Should be fixed momentarily. Sorry.
01-04-2021
[~dholmes] David, you mean use -Djava.util.concurrent.ForkJoinPool.common.parallelism=<# cores> ? Or is there another recommendation? I can re test it.
01-04-2021
See also JDK-8264572 - it seems there is a bug with the common pool parallelism level being set to 1. Explicitly setting the parallelism level should restore performance and confirm this is the cause.
01-04-2021