Replace IOUtils thread local usage with loom friendly pooling #3239
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
| /test |
JonasKunz force-pushed the loom-friendly-pooling branch from 2042012 to e0c900a Compare 5 tasks
jackshirazi approved these changes Jul 25, 2023
# Conflicts: # CHANGELOG.asciidoc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Part of #3059.
Our
IOUtilsuses thread-locals for reusingByteBuffer(2kb size) andCharsetDecoders.This usage is not feasible with virtual threads, because 1 million threads for example would equate to 2gb memory usage due to the bytebuffers.
This PR replaces the thread-local based pooling with a queue based pool which we already use for other recycling use-cases. A new
ObjectHandle-variant has been added to make the usage safe and easy via try-with-resources.Resource pooling via a queue is expected to be more expensive than thread-local based pooling, as it involves at least two atomic CAS operations. Those should however not be to costly, as we expect low contention.
An alternative approach would be to use thread-locals for platform threads and queue based pooling for virtual threads, but I would expect the complexity here to not be worth it.
Checklist