[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