RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit

[David Lloyd]

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



-- 
- DML