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

[Alan Bateman]

On Wed, 28 May 2025 14:27:40 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/jdk/internal/access/JavaLangAccess.java line 549:
> 
>> 547:     void removeCarrierThreadLocal(CarrierThreadLocal<?> local);
>> 548: 
>> 549:     /**
> 
> Copyright update?

It's already up to date so no change.

> src/java.base/share/classes/jdk/internal/misc/TerminatingThreadLocal.java line 82:
> 
>> 80:      */
>> 81:     public static void register(TerminatingThreadLocal<?> tl) {
>> 82:         if (tl != REGISTRY) {
> 
> Would this happen in any well-behaved application? If not, might be better to throw an exception? 🤔

It's just a consequence of the registry being a ttl, we either check it here or in set, it's more local here.

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

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