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

[Tony Printezis]

Hey Peter,

I had written a test to test my version of the exit hooks. I can easily
rework it to work with yours. Interested?

To check that the native buffers are reclaimed promptly, we should be able
to amend the test that tests the setting of the max size for the cached
buffers (i.e., check that, after all the threads have exited, the total
native count / size is 0).

Tony


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


On June 20, 2018 at 10:08:48 AM, Peter Levart (peter.levart at gmail.com)
wrote:


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