On 04/09/18 08:25, David Holmes wrote:

On 7/04/2018 3:11 AM, Tony Printezis wrote:
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com

On April 6, 2018 at 12:16:10 PM, David Lloyd (david.ll...@redhat.com) wrote:

On Fri, Apr 6, 2018 at 8:57 AM, Tony Printezis <tprinte...@twitter.com>
ThreadLocal clearing

Could you clarify what you mean by ThreadLocal clearing?

I mean calling ThreadLocal#remove().

I see. So, anyone who subclasses ThreadLocal can override remove(). And if remove() is called by Thread::exit, it can be used as an exit hook. (David
Holmes, if this is what you meant in your e-mail: apologies; I

Absolutely! ... Well kind of ... okay actually no, I wasn't thinking at that level of detail yet. ;-)

David H.

There's no need in calling ThreadLocal.remove() at thread exit as Thread.exit() method already does that (sort of):

    private void exit() {
        threadLocals = null;
        inheritableThreadLocals = null;

After thread exits, ThreadLocal values associated with it are no longer reachable from its Thread object.

The problem Tony faces is that by the time this happens, direct ByteBuffer's that were cached using such ThreadLocal value, are already moved to old GC generation, waiting for full GC to release them together with direct memory they are holding.

So what is needed is an internal call-back registration API Alan is proposing and (maybe just internal) probing method for ThreadLocal that return(s) the associated value only when it has already been initialized.

Regards, Peter

I like the suggestion to add an overridable exit() method to ThreadLocal.
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.

It's more complexity, and at some point you have to ask: is it better
to block thread A or thread B? At least blocking thread A is somewhat

I agree re: it’d add complexity. #simplify :-)


Reply via email to