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

[Tony Printezis]

Alan,

Thanks for your thoughts!

Peter,

Any chance of taking the two suggestions I made in an earlier e-mail into
account?

a) It’d be nice if users can override initialValue(), like when using the
standard ThreadLocal class, instead of calculateInitialValue(). (I can’t
come up with a clean solution on how to do that, though. I’ll think about
it for a bit.)
b) It’d be very helpful to pass T value to threadTerminated(), as I cannot
imagine many use-cases where the value will not be needed.

Re: renaming JdkThreadLocal: ThreadLocalWithExitHooks?

Re: exposing getIfPresent() : Yes! Pretty please! :-) This will be very
helpful and can avoid completely unnecessary allocations.

Tony


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


On June 6, 2018 at 9:38:05 AM, Alan Bateman (alan.bateman at oracle.com) wrote:



On 30/05/2018 22:16, Peter Levart wrote:
> I thought there would be some hint from Alan about which of the two
> paths we should take for more refinement.
>
> The Tony's:
>
> http://cr.openjdk.java.net/~tonyp/8202788/webrev.1/
>
> Or the Alan's with my mods:
>
> http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.02/
>
Finally getting back to this one.

I don't think the two approaches are all that different now. Tony's
point on the number of hooks vs. number of locals was an important point
but with Peter's update to use a thread local registry then I think we
have easy to maintain solution in the DBBCache_Cleanup/webrev.02 patch.
So I think I prefer that approach. We need to better name for
"JdkThreadLocal", something to indicate that it holds resources or it
notified when a thread terminates.

Also along the way, we touched on exposing getIfPresent and we should
look at that again. If it is expose then it fits well with the second
approach too.

-Alan