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 | tprinte...@twitter.com On June 20, 2018 at 10:08:48 AM, Peter Levart (peter.lev...@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
