RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit (original) (raw)

Peter Levart peter.levart at gmail.com
Sat May 12 10:44:06 UTC 2018

Hi,

On 05/11/18 16:13, Alan Bateman wrote:

On 08/05/2018 16:07, Tony Printezis wrote:

Hi all,

Following the discussion on this a few weeks ago, here’s the first version of the change: http://cr.openjdk.java.net/~tonyp/8202788/webrev.0/ I think the consensus was that it’d be easier if the exit hooks were only available within java.base. Is it enough that I added the functionality to the jdk.internal.misc package? (And is jdk.internal.misc the best place for this?) I’ll also add a test for the new functionality. But let’s first come up with an approach that everyone is happy with. :-) Peter's approach in early April was clean (and we should come to the getIfPresent discussion) but it adds a field to Thread for the callback list. If I read your approach correctly, you are avoiding that by maintaining an array of hooks in ThreadLocalExitHooks. Another approach to try is a java.base-internal ThreadLocal that defines a method to be invoked when a thread terminates. Something like the following: http://cr.openjdk.java.net/~alanb/8202788/webrev/index.html -Alan

From the API perspective, Alan's suggestion is the most attractive one as it puts the method to where it belongs - into the ThreadLocal instance. But the implementation could be improved a bit. I don't like the necessity to iterate over all ThreadLocal(s) to filter out JdkThreadLocal(s). There might be a situation where there's plenty of ThreadLocal(s) registered per exiting thread which would produce a spike in CPU processing at thread exit.

The way to avoid this would be to maintain a separate linked list of entries that contains just those with JdkThreadLocal(s). Like in this modification of Alan's patch, for example:

http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.01/

(Only ThreadLocal class is modified from Alan's patch)

What do you think?

Regards, Peter

More information about the core-libs-dev mailing list