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

Ron Pressler ron.pressler at oracle.com
Wed Jul 3 14:12:53 UTC 2024



> On 2 Jul 2024, at 19:41, robert engels <rengels at ix.netcom.com> wrote:
> 
> Is this in an effort to allow the automatic clean-up the OP refers to?

Not cleanup, but memory reclamation. If a thread provably can never continue, it can continue running forever (conceptually) without consuming any RAM (although you want be able to observe it). If a thread can never do anything, it behaves exactly as if the thread doesn’t exist.

> 
> 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).

It would only “function” differently in the sense that observability (i.e. a thread dump) and memory consumption would be different, which are not considered functional changes by the spec.

> 
>> 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://urldefense.com/v3/__https://stackoverflow.com/questions/78596905/why-virtual-thread-is-not-garbage-collected-when-not-reachable__;!!ACWV5N9M2RV99hQ!ISk6c21Jkzy3I92KCoA9udUUidpoMoyHTAGx1uC1gzAqH-hBQkxNMLRu6VEZxznn3M45Lbt-tlqmYwlNEQ$ 
>>> 
>>> 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
>>> 
>> 
> 



More information about the loom-dev mailing list