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.

[brettwooldridge]

Ah, I don't know how I lost the change I had made, but I did somehow. The way that I intended to solve it, and had at some point but must have reverted it, was to insert this before the return ref:

// Ensure that obj is referencable past the enqueue point.
if (obj == null) {
   throw new IllegalArgumentException("Cleaner object cannot be null");
}

I believe that should address it. Can you test it?

If that does not fix it, remove synchronized from the method signature, and do this:

public Cleanable register(final Object obj, final Runnable cleanupTask) {
   // The important side effect is the PhantomReference, that is yielded after the referent is GCed
   final CleanerRef ref = new CleanerRef(obj, referenceQueue, cleanupTask);

   synchronized (this) {
        // everything else
        ...
   }

   // Ensure that obj is referencable past the enqueue point.
   if (obj == null) {
      throw new IllegalArgumentException("Cleaner object cannot be null");
   }
   return ref;
}

EDIT: I updated the pull request with this later fix.

[brettwooldridge]

I believe this change should work. The compiler cannot reorder the conditional before the synchronized block, and it cannot eliminate the reference bc it cannot know whether it is null or not.

By the way, really nice work on this class. Outside of this change, I simply don't see any way it could possibly be more efficient. I love seeing code like this.

[matthiasblaesing]

Thanks for the update. I run a few measurements based on you suggested invocation. And these are the results:

measure.ods

For "Tabelle 1" I ran 5.18.1 as baseline and your branch as comparison (title is "modified" then). Looking at the Diff I see mostly positive effects for the first run variant, but even there I see one run that regressed. The second run variant allways comes out slower. This also holds when averaging the values.

"Tabelle 2" is mostly identical to the first experiment, but I introduced the "check non null" in register onto master (that is master-synced) and ran that for comparison.

It is hard to draw a conclusion from this. My runtime environment is a bad example though (Notebook).

Could you please have a look and maybe rerun your numbers?