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

Tony Printezis tprintezis at twitter.com
Tue Jun 19 19:31:19 UTC 2018


Good idea, as long as it re-uses the existing ThreadLocal infrastructure
and doesn’t introduce an extra per-thread map. Making it a ThreadLocal
subclass would be an excellent start.

Tony

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


On June 19, 2018 at 9:07:07 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.

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


More information about the core-libs-dev mailing list