-
Notifications
You must be signed in to change notification settings - Fork 1.7k
fixes #1616 tighten up synchronization and conditional logic #1688
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
fixes #1616 tighten up synchronization and conditional logic #1688
Conversation
There was a problem hiding this 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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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):
Lower-memory, threads matching core count:
Tests run on an Epyc 7402 Proxmox VM
High-memory high-threading (2x core count):
Lower-memory, threads matching core count: