-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Remove locks from StupidPool #1601
Conversation
log.warn("Not closed! Object was[%s]. Allowing gc to prevent leak.", object); | ||
} | ||
super.finalize(); |
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 wonder why this wasn't there before?
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.
if we need to add it, it should probably be in a finalize block to ensure it gets run no matter what happens
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.
Object.finalize
is a no-op in the basic source code. It seemed like a bad idea not to have it present though.
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.
Added in finally block
ba5e6e4
to
7cc83d3
Compare
LGTM, some benchmarks or indication it resolved the issue you were seeing would be good though |
7cc83d3
to
7fe8562
Compare
Production systems spend a shocking amount of cpu time in StupidPool.close (on the order of 18%) this is an attempt to reduce that footprint.
Simply looking at the stupidpool stats:
Master: 1.308 ± 0.067 ops/us
This PR: 4.7~5.1 ops/us
This PR is harder to benchmark because it is bound by ObjectResourceHolder and the garbage created that way.
Master is slow enough not to hit that bound.