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

David Lloyd david.lloyd at redhat.com
Tue May 8 15:43:30 UTC 2018

I'm not a reviewer, but I would ask: how sure are we that it's OK to use lambdas from here? Is there a chance that the magic bootstrap stuff won't yet be initialized at the time when an early thread could exit for whatever reason?

Anyway I think using a lambda with forEach is probably overkill in atThreadExit. A simple for loop would suffice IMO.

Also, I would be quite surprised if there wasn't a way to get a system property from system code without having to use doPrivileged; that might bear some researching.

Could this all be simplified to drop the necessity for passing around the thread local map and thread local instances? The sun.nio.ch.Util has static access to its ThreadLocal, so really all it needs is to be able to give a Runnable to run at thread exit and it can take care of the rest. It could be a simple as keeping an ArrayList of Runnables on Thread or in another ThreadLocal.

On Tue, May 8, 2018 at 10:07 AM, Tony Printezis <tprintezis at twitter.com> 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. :-) One additional question: I put the new functionality conditional on a property (jdk.nio.freeBuffersAtThreadExit) and it’s off by default. Should I make it on by default? Or just not add the property all-together? Tony

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

--

More information about the core-libs-dev mailing list