On 04/09/18 12:21, Peter Levart wrote:
On 04/09/18 10:33, David Holmes wrote:
After thread exits, ThreadLocal values associated with it are no
longer reachable from its Thread object.
The problem Tony faces is that by the time this happens, direct
ByteBuffer's that were cached using such ThreadLocal value, are
already moved to old GC generation, waiting for full GC to release
them together with direct memory they are holding.
Right. So the suggestion was to call ThreadLocal.remove() instead (as
well as?) so that you could define a custom ThreadLocal class for the
buffers that override remove() to actually release the buffer directly.
David
Ah, of course. But the concern is that custom code at thread-exit is
not desirable. Alan is propagating private internal API. Here's a
prototype:
http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.00/
Would something like this be acceptable?
Regards, Peter
If adding a field to Thread class is a concern, I can modify this to use
a special ThreadLocal instance to keep registered callback(s) per thread.
Regards, Peter
