Date      October 11, 2023 at 3:02 PM
  From:     Rob Riepel <riepel@stanford.edu>
  Subject:  bias locks - our java 17 problem

  I've been searching for 11 vs 17 performance issues since we noticed the problem, but
  only finding that 17 is 8.66% faster at something or other. :-( But I finally got
  lucky and found something that seems to apply:

    https://dev.to/vbochenin/java-17-migration-bias-locks-regression-2c5m

  I tried the quick and dirty check therein and it works. Runtimes are now roughly equal:

    JAVA_HOME=/opt/riepel/java JRUBY_OPTS="-J-Xmx2g -J-Xss8m -J-Xms512m"  11 >   150.18s user 1.36s system 130% cpu 1:55.87 total
    JAVA_HOME=/opt/riepel/java JRUBY_OPTS="-J-Xmx2g -J-Xss8m -J-Xms512m"  11 >   150.83s user 1.02s system 120% cpu 2:06.02 total
    JAVA_HOME=/opt/riepel/java JRUBY_OPTS="-J-Xmx2g -J-Xss8m -J-Xms512m"  11 >   151.59s user 1.16s system 122% cpu 2:04.94 total
    JAVA_HOME=/opt/riepel/java JRUBY_OPTS="-J-Xmx2g -J-Xss8m -J-Xms512m"  11 >   151.67s user 1.02s system 123% cpu 2:04.07 total
    JAVA_HOME=/opt/riepel/java JRUBY_OPTS="-J-Xmx2g -J-Xss8m -J-Xms512m"  11 >   160.39s user 1.21s system 130% cpu 2:04.19 total
    JAVA_HOME=/opt/riepel/java JRUBY_OPTS="-J-Xmx2g -J-Xss8m -J-Xms512m"  11 >   183.68s user 1.30s system 150% cpu 2:02.60 total

    JAVA_HOME=/opt/riepel/java JAVA_OPTS="-XX:+UseBiasedLocking" JRUBY_OPTS=  17 132.61s user 1.41s system 110% cpu 2:01.50 total
    JAVA_HOME=/opt/riepel/java JAVA_OPTS="-XX:+UseBiasedLocking" JRUBY_OPTS=  17 136.18s user 1.30s system 112% cpu 2:02.15 total
    JAVA_HOME=/opt/riepel/java JAVA_OPTS="-XX:+UseBiasedLocking" JRUBY_OPTS=  17 140.85s user 1.44s system 108% cpu 2:10.96 total
    JAVA_HOME=/opt/riepel/java JAVA_OPTS="-XX:+UseBiasedLocking" JRUBY_OPTS=  17 142.44s user 1.66s system 110% cpu 2:10.52 total
    JAVA_HOME=/opt/riepel/java JAVA_OPTS="-XX:+UseBiasedLocking" JRUBY_OPTS=  17 143.70s user 1.42s system 109% cpu 2:12.24 total
    JAVA_HOME=/opt/riepel/java JAVA_OPTS="-XX:+UseBiasedLocking" JRUBY_OPTS=  17 152.23s user 1.43s system 111% cpu 2:17.89 total

  I ported the test to java to make sure JRuby wasn't the problem. It's not:

    java -cp ./netdb_rmi.jar:. sizetest >&/dev/null                        189.48s user 1.24s system 103% cpu 3:04.01 total
    java -cp ./netdb_rmi.jar:. sizetest >&/dev/null                        182.34s user 1.01s system 102% cpu 2:58.96 total
    java -cp ./netdb_rmi.jar:. sizetest >&/dev/null                        184.90s user 1.08s system 102% cpu 3:01.27 total
    java -cp ./netdb_rmi.jar:. sizetest >&/dev/null                        191.96s user 1.28s system 102% cpu 3:08.27 total
    java -cp ./netdb_rmi.jar:. sizetest >&/dev/null                        184.65s user 0.99s system 102% cpu 3:00.98 total

    java -XX:+UseBiasedLocking -cp ./netdb_rmi.jar:. sizetest >&/dev/null  137.65s user 0.99s system 103% cpu 2:14.29 total
    java -XX:+UseBiasedLocking -cp ./netdb_rmi.jar:. sizetest >&/dev/null  125.95s user 0.99s system 103% cpu 2:02.92 total
    java -XX:+UseBiasedLocking -cp ./netdb_rmi.jar:. sizetest >&/dev/null  130.99s user 1.18s system 104% cpu 2:06.16 total
    java -XX:+UseBiasedLocking -cp ./netdb_rmi.jar:. sizetest >&/dev/null  132.11s user 1.16s system 104% cpu 2:07.46 total
    java -XX:+UseBiasedLocking -cp ./netdb_rmi.jar:. sizetest >&/dev/null  130.77s user 1.05s system 104% cpu 2:06.59 total

  Hopefully the real fix makes sense to you and our bias lock instances are easy to find and fix.