RFR: 8357637: Native resources cached in thread locals not released when FJP common pool threads clears thread locals

[Alan Bateman]

On Tue, 27 May 2025 12:10:19 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> A ForkJoinPool can be created with worker threads that clear thread locals between tasks, thus avoiding a build up of thread locals left behind by tasks executed in the pool. The common pool does this. Erasing thread locals (by writing null to Thread.threadLocals) grinds with thread locals that keep native memory alive, esp. when there isn't a Cleaner or other means to free the memory.
>> 
>> For the JDK, this is currently an issue for the NIO direct buffer cache. If a task running on a thread in the common pool does socket or network channel I/O then it can leak when the task terminates. Prior to JDK 24 each buffer in the cache had a cleaner, as if allocated by ByteBuffer.allocateDirect, so it had some chance of being released. The changes in [JDK-8344882](https://bugs.openjdk.org/browse/JDK-8344882) mean there is no longer is cleaner for buffers in the cache.
>> 
>> The options in the short term are to restore the cleaner, register a clearer for the buffer cache, have the FJP resetThreadLocals special case "terminating thread locals", or move the terminating thread locals to a different TL map. Viktor Klang, Doug Lea, and I discussed this topic recently and agreed the best short term approach is to split the map. As terminating thread locals are for platform threads then the map can be in the Thread.FieldHolder and avoid adding another field to Thread. Medium to long term require further thought in this area, including seeing what might be useful (and safe) to expose.
>> 
>> Testing 1-5. Performance testing ongoing.
>
> src/java.base/share/classes/java/lang/Thread.java line 246:
> 
>> 244:         volatile boolean daemon;
>> 245:         volatile int threadStatus;
>> 246:         ThreadLocal.ThreadLocalMap terminatingThreadLocals;
> 
> I think it's worth documenting the memory safety aspects of this field.

Comment added to make it clear that it is maintained by the TL class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2115642472