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

[robert engels]

But won’t that be a breaking api change:

/**
     * Retrieves and removes the head of this queue, waiting if necessary
     * until an element becomes available.
     *
     * @return the head of this queue
     * @throws InterruptedException if interrupted while waiting
     */
    E take() throws InterruptedException;

For example, given this code:

T timedGetElement() throws InterruptedException {
  Timer t = Timer.start();
   try {
      return queue.take();
   } finally {
      t.stop();
   }
}

With the proposed changes, stop() may never be called - leading to potential resource leaks.

Whereas currently the rules ensure stop() will be called unless the application hard terminates. This would essentially equating thread “death” with a hard application termination from an observability standpoint.

You would have similar issues with any tracing/logging type frameworks.


> On Jul 3, 2024, at 9:12 AM, Ron Pressler <ron.pressler at oracle.com> wrote:
> 
> 
> 
>> On 2 Jul 2024, at 19:41, robert engels <rengels at ix.netcom.com <mailto: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$ <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 <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/20240703/126be537/attachment.htm>