[External] : Re: Virtual thread memory leak because TrackingRootContainer keeps threads

Alan Bateman Alan.Bateman at oracle.com
Tue Jul 9 14:24:01 UTC 2024


On 09/07/2024 12:51, Michal Domagala wrote:
> Thanks for valuable observability context
>
> As I understand, initially VT created by Thread API was not observable 
> in thread dump and VT created by Executors API was observable. It was 
> confusing and now both kinds of VT are observable. Make sense.
> But observability is reached by strong reference. VT created by Thread 
> API are strongly referenced until stop and not GC'ed until stop and VT 
> created by Executors API are not referenced at all and GC'ed when not 
> reachable, regardless of being stopped or not. That's not OK and much 
> worse than previous confusion.

An ExecutorService implementation has to keep a reference to each 
task/thread because of the shutdownNow and close method. There are other 
thread groupings that arise when using structured concurrency that 
require a thread executing a main task wait for threads executing 
subtasks to finish executing.

As things stand I don't expect there will be much confusion. For 25+ 
years, a started thread is alive (and strongly reachable) until it 
terminates. Having virtual thread work mostly the same shouldn't be a 
surprise. As I said, the door hasn't been closed on introducing some 
notion of ephemeral thread in the future. It's not really feasible right 
now because of finalization and because of several issues related to 
cleaner actions and explicit APIs to keep some object reachable until a 
thread gets to some point in its execution. So there is more to this 
than just observability (and yes of course observability could traverse 
other reference types if needed).

As regards the thread counting in the root container when running with 
the undocumented system property jdk.trackAllThreads is set to false. 
That is the count of the live (started but not terminated) threads in 
that thread grouping. It is a left over from when we will mulling over 
what the right default should be (reporting a thread count when you 
can't list the threads has some value).

-Alan


More information about the loom-dev mailing list