RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit
Peter Levart
peter.levart at gmail.com
Wed Jun 20 14:08:46 UTC 2018
On 06/18/2018 05:41 PM, Alan Bateman wrote:
>
>
> On 17/06/2018 22:20, Peter Levart wrote:
>> Update: the discussion on concurrent-interest about possible future
>> addition of public ThreadLocal.getIfPresent() or
>> ThreadLocal.isPresent() has died out, but it nevertheless reached a
>> point where ThreadLocal.isPresent() was found the least problematic.
>> So I would like to get further with this proposal using the last
>> webrev.04 version of the patch that uses ThreadLocal.isPresent()
>> internally - still package-private at the moment.
>>
>> Here's the webrev (unchanged from the day it was published):
>>
>> http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.04/
>>
>> Would this version be OK?
> I think looks quite good.
>
> One small nit is that the update to ThreadLocal.setInitialValue makes
> it look like all locals are registered when setting the initial value.
> What would you think about moving the instanceof check from
> TerminatingThreadLocal.register so that it's a bit more obvious.
>
> -Alan
Like the following?
http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.05/
Do we need a test which proves that cached direct buffers are released
when thread exits or would a unit test for TerminatingThreadLocal be
enough? Maybe both?
Regards, Peter
More information about the core-libs-dev
mailing list