On Tue, 27 May 2025 12:14:16 GMT, Viktor Klang <vkl...@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/ThreadLocal.java line 284: > >> 282: */ >> 283: ThreadLocalMap getMap(Thread t) { >> 284: if (this instanceof TerminatingThreadLocal<T>) { > > Would it make sense to override `getMap` in TerminatingThreadLocal instead? `TerminatingThreadLocal` is located in the `jdk.internal.misc` package, so that’s not a possibility without introducing `module‑protected` visibility, which was decided against during development of **Project Jigsaw**, as it would further complicate the already complex method resolution rules. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25457#discussion_r2111405993
