Skip to content

Conversation

@brettwooldridge
Copy link
Contributor

@brettwooldridge brettwooldridge commented Sep 26, 2025

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

Copy link
Member

@matthiasblaesing matthiasblaesing left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

cleanerRunning = true;
}

return ref;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

@brettwooldridge brettwooldridge Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

@brettwooldridge brettwooldridge Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants