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