fixes #1616 tighten up synchronization and conditional logic

[brettwooldridge]

Cleaner Revenge Tour 😄

Ok, this refactor leaves the doubly linked-list intact but tightens up the conditional logic around the node linking/unlinking, as well as reducing the method invocation overhead in some code paths. All-in-all an extremely minor refactor but seemingly does well in the JMH harness.

Tests run on a M1 Ultra Mac Studio.

High-memory high-threading (2x core count):

java -Xmx20g -jar target/benchmarks.jar -t 16 -i 5 -wi 6

5.18.0
Benchmark                Mode  Cnt       Score        Error  Units
MyBenchmark.testMethod  thrpt   25  550361.312 ± 452304.324  ops/s

5.19.0-SNAPSHOT
Benchmark                Mode  Cnt       Score        Error  Units
MyBenchmark.testMethod  thrpt   25  806701.763 ± 548298.436  ops/s

Lower-memory, threads matching core count:

java -Xmx16g -jar target/benchmarks.jar -t 8 -i 5 -wi 6

5.18.0
Benchmark                Mode  Cnt       Score        Error  Units
MyBenchmark.testMethod  thrpt   25  216233.155 ± 209346.033  ops/s

5.19.0-SNAPSHOT
Benchmark                Mode  Cnt       Score        Error  Units
MyBenchmark.testMethod  thrpt   25  313306.938 ± 324647.767  ops/s

Tests run on an Epyc 7402 Proxmox VM

High-memory high-threading (2x core count):

java -Xmx20g -jar target/benchmarks.jar -t 16 -i 5 -wi 6

5.18.0
Benchmark                Mode  Cnt        Score       Error  Units
MyBenchmark.testMethod  thrpt   25  1003122.171 ± 88700.984  ops/s

5.19.0-SNAPSHOT
Benchmark                Mode  Cnt        Score        Error  Units
MyBenchmark.testMethod  thrpt   25  1057712.282 ± 105237.902  ops/s

Lower-memory, threads matching core count:

java -Xmx16g -jar target/benchmarks.jar -t 8 -i 5 -wi 6

5.18.0
Benchmark                Mode  Cnt       Score       Error  Units
MyBenchmark.testMethod  thrpt   25   948151.717 ± 50740.821  ops/s

5.19.0-SNAPSHOT
Benchmark                Mode  Cnt        Score       Error  Units
MyBenchmark.testMethod  thrpt   25  1020379.664 ± 82178.334  ops/s

[matthiasblaesing]

I can reproduce improved numbers with the provided jmh invocations (thanks for that). I left one inline comment. Could please check if you agree and see if the numbers still hold up if a fix is applied?

[matthiasblaesing]

At this point we need the equivalent of Reference.reachabilityFence on obj. If the caller does not retain a strong reference, we need to ensure, that the reference is kept at least until the reference cleaner is completely enqueued. As observed in the last iteration early GC can happen: #1684 (comment).

In the comment I suggested to use an empty sychronized block.