Virtual thread memory leak because TrackingRootContainer keeps threads

[robert engels]

Is this in an effort to allow the automatic clean-up the OP refers to?

Wouldn’t this make the code function differently if called by a VT vs a PT? This seems like a huge problem to me and against the design of VT (and Java for that matter).

> On Jul 2, 2024, at 1:08 PM, Ron Pressler <ron.pressler at oracle.com> wrote:
> 
> We would eventually like to allow setting tracking option on a per-thread basis, but we need to work out a few details.
> 
>> On 1 Jul 2024, at 20:08, Michal Domagala <outsider404 at gmail.com> wrote:
>> 
>> According to 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
>> 
>> The problem was not visible since 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
>> 
>