Virtual thread memory leak because TrackingRootContainer keeps threads

[Robert Engels]

I am not sure you can call it a memory leak - you would have the same problem if it was a platform thread - it would be stuck waiting on a queue - and so any references the thread held in its stack would “leak” as well.

Having two different behaviors for platform and virtual threads in this regard would cause a lot of problems with interoperability (switching between thread types).

I don’t think a code author should need to know if their resources are being used by a virtual thread or a platform thread and adjust.

Treating VT threads as GC roots make more sense to me.


> On Jul 1, 2024, at 2:08 PM, Michal Domagala <outsider404 at gmail.com> 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
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240701/c22c8d8f/attachment.htm>