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

[Martin Buchholz]

On Tue, Jun 19, 2018 at 6:06 AM, David Lloyd <david.lloyd at redhat.com> wrote:

> It may be confusing (to some, I guess) but it is consistent: the
> ThreadLocal subclass author has absolute control over how the value is
> presented to the user.  Adding compute() or many of the other
> suggested variants will break that guarantee, which seems like kind of
> a big deal to me.
>
>
Yeah, that's a good point I didn't consider.  Any new method tends to
expose presence/absence and evade subclass' checking.  OTOH I think the
same has happened with default methods added to existing interfaces,
including Map, and I don't recall complaints about the failure of
encapsulation.  In this way, again ThreadLocal.compute would be very much
like Map.compute.


> What about introducing a different thread local API that has more
> modern behavior?  Maybe a new subclass of ThreadLocal?
>
>
The hard part is coming up with a good name.
ThreadLocalNowWithExtraMappiness ?

If we create a new class, we can consider giving get() non-mutating
behavior consistent with Map.