Promptly freeing the per-thread cached direct buffers when a thread exits

[Tony Printezis]

Hi David,

Thanks for your thoughts. Please see inline.


—————
Tony Printezis | @TonyPrintezis | tprintezis at twitter.com


On April 5, 2018 at 6:24:11 PM, David Lloyd (david.lloyd at redhat.com) wrote:

On Thu, Apr 5, 2018 at 4:45 PM, Tony Printezis <tprintezis at twitter.com>
wrote:
> Would proposing to introduce thread exit hooks be reasonable? Or is
> everyone going to freak out? :-) The hooks can be either per-Thread or
even
> per-ThreadLocal. And it's OK if the hooks can only be used within
java.base.

User-accessible thread exit hooks would be nice, from a user
perspective. From a JDK perspective - it adds new opportunities for
user code to jam things up, so it's a tradeoff.


…just like finalizers. :-) Yeah, I get that. Which is why I was a bit
reluctant to bring it up. Which is why I proposed to only make it available
within java.base?



ThreadLocal clearing


Could you clarify what you mean by ThreadLocal clearing?


on thread exit would have been nice back in the
beginning, but now I think it would be a fairly substantial behavior
change. Adding a new exit() method on ThreadLocal would be better
(but not perfect) compatibility-wise, and see prior note about users
jamming things up...


I like the suggestion to add an overridable exit() method to ThreadLocal.
If you want to avoid calling user code by Thread::exit, would adding
ThreadLocals (which are tagged appropriately) to a queue for later
processing a better approach (similar to the mechanism used for References
/ ReferencesQueues)? The user can of course create a memory leak by not
polling the queue frequently enough. But, that’s also the case for
References. And at least user code cannot block Thread::exit.



I think that at a minimum, explicitly releasing thread-local NIO
direct buffers on thread exit (without introducing a user facing API)
is probably safe.


I’m also pretty sure it’s safe. I should have mentioned that the
thread-local direct buffers are actually explicitly freed when they are not
put back in the cache. So, it should be safe to also explicitly free any
that are in the cache when the thread exits.


Some kind of user-accessible hook would be nice,
but I can't imagine it would take anything less than a massive
discussion to get there.


I’d like to avoid a massive discussion, which is why I proposed to only
make it available within java.base.

Tony



-- 
- DML