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

[Tony Printezis]

Alan and Peter,

First, I need to apologize: I completely missed Peter’s proposal (for some
reason Peter’s follow-up e-mails show up blank on my mail client). Could
someone point me to it so I can take a look?

Re: having info per thread vs. globally: Having a couple more objects and a
field per-thread will probably not be a huge deal, memory footprint-wise.
But, and with my GC implementer hat on :-), avoiding that and only
maintaining a single global entry per-ThreadLocal can only be a good thing,
IMHO.

Re: Alan’s approach vs. my approach: I like Alan’s approach given that it
doesn’t require any additional data structures / memory footprint to keep
track of the hooks (only an extra class). The only downside I can think of
is that it requires an iteration over all entries in each ThreadLocal map
even if there are no ThreadLocals with an exit hook. My proposal only
iterates over the exit hooks (and it’s essentially a nop if there are
none). If we assume there will be a very small number of exit hooks, and
potentially many entries in some TL maps, this will be a win and keep
Thread::exit a bit leaner.

Having said all this, I’ll be very happy to just get this fix done. So,
feel free to decide on which approach is most appropriate! :-) I’ll be
happy with any of the proposals.

Tony


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


On May 11, 2018 at 10:13:30 AM, Alan Bateman (alan.bateman at oracle.com)
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