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

[David Lloyd]

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.

What about introducing a different thread local API that has more
modern behavior?  Maybe a new subclass of ThreadLocal?

On Mon, Jun 18, 2018 at 5:28 PM Martin Buchholz <martinrb at google.com> wrote:
>
> yes, the proposed new methods would use nulls differently.  The original get() behavior of creating a mapping was a mistake, inconsistent with Map.  Yes, it will cause confusion.  But it's already confusing.
>
> On Mon, Jun 18, 2018 at 1:45 PM, David Lloyd <david.lloyd at redhat.com> wrote:
>>
>> On Mon, Jun 18, 2018 at 12:53 PM, Martin Buchholz <martinrb at google.com> wrote:
>> > On Mon, Jun 18, 2018 at 10:21 AM, Tony Printezis <tprintezis at twitter.com>
>> > wrote:
>> >
>> >> Martin,
>> >>
>> >> You are forgiven. :-)
>> >>
>> >> So, the (valid, I think) issue with getIfPresent(), as originally proposed
>> >> by Peter, was that if get() was overridden in the subclass to somehow
>> >> transform the returned value, getIfPresent() wouldn’t apply the same
>> >> transformation.
>> >>
>> >> Doesn’t your compute() method have essentially the same issue? Apart from
>> >> that, I personally like this proposal as I agree: one look-up is always
>> >> better than two.
>> >>
>> >>
>> > A non-prototype implementation would delegate compute into ThreadLocalMap
>> > itself, where there is no risk of overriding.
>>
>> I don't think overriding is the risk; the risk would be compute*
>> behaving inconsistently with regards to an overridden get*.
>>
>>
>> --
>> - DML
>
>


-- 
- DML