Virtual thread memory leak because TrackingRootContainer keeps threads

[Brian S O'Neill]

I was confused when I first discovered that virtual threads could be 
GC'd when blocked with an infinite timeout. This was before the 
trackAllThreads option was enabled by default.

If the virtual thread is blocked with an effectively infinite timeout 
(100 years), it won't be GC'd even when trackAllThreads is false. For 
consistency, I think it makes sense for virtual threads to never 
actually be GC'd except until after they exit.

If you depended on virtual threads being GC'd when blocked with a real 
infinite timeout, then switching to platform threads would introduce a 
memory leak that didn't exist before. Ideally, the two thread types 
should be interchangeable.


On 2024-07-01 12:08 PM, Michal Domagala wrote:
> According to https://openjdk.org/jeps/444 <https://openjdk.org/jeps/444>,
> 
> "Unlike platform thread stacks, virtual thread stacks are not GC roots."
> 
> But jdk.internal.vm.ThreadContainers.RootContainer.TrackingRootContainer#VTHREADS keeps (hard) references to each virtual thread. Effectively, virtual threads are GC roots.
> 
> I described full example here: 
> https://stackoverflow.com/questions/78596905/why-virtual-thread-is-not-garbage-collected-when-not-reachable <https://stackoverflow.com/questions/78596905/why-virtual-thread-is-not-garbage-collected-when-not-reachable>
> 
> The problem was not visible since 
> https://bugs.openjdk.org/browse/JDK-8309406 
> <https://bugs.openjdk.org/browse/JDK-8309406>, because before the 
> change, VTHREADS "keep" was not enabled and i guess nobody cares memory 
> leak.
> 
> But after the change every JVM is affected.
> 
> A workaround for memory leak is set jdk.trackAllThreads=false
> 
> Best regards
> Michal Domagala
>