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

[Alan Bateman]

On 08/07/2024 22:12, Michal Domagala wrote:
> Hi
>
> As a thread author, I would like to say I opened the thread because I 
> could not report a memory leak as a bug. Page 
> https://bugreport.java.com/bugreport/submit_start 
> <https://urldefense.com/v3/__https://bugreport.java.com/bugreport/submit_start__;!!ACWV5N9M2RV99hQ!O3-6Y8rB_Q3TnOXLeIa2WkhSm-X8hYgCkqwGAG4EqpVKaFgdKdh4kpH4juXWBBVbkBbMxFZDjRsTawE7Yeih$> 
> does not work.
>
> In my understanding JEP 444 is finished and delivered in JDK 21. Any 
> deviation between JEP 444 and JDK 21 is a bug.
> I hoped somebody will say "OMG" and start fixing procedure. But it 
> seems to me discussion concerns on JEP 444 - good or bad decision was 
> taken.
>
> Personally, I have high confidence in the written word. Written word 
> convinced me that VT is GC'ed. It's very interesting to see other 
> opinions, but in my understanding the time is out of joint and 
> seek for help to set it right
>

The topic you brought up was an open question when virtual threads were 
a preview feature in JDK 19/20. For JDK 19/20, virtual threads created 
directly with the Thread API were only only kept strongly reachable when 
doing some operation that may continue (blocked on I/O, timer, ...). 
This meant that, in some cases, "abandoned" virtual threads could be 
GC'ed even though they had not terminated.

The main thing that came up during the preview period was observability. 
There were several questions here as to why virtual threads created 
directly with the Thread API didn't show up in thread dumps. It was 
surprising when virtual threads in other thread groupings (e.g. 
Executors.newVirtualThreadPerTaskExecutor) did appear in the thread 
dump. This was part of the motivation to change things before virtual 
threads became a permanent feature (see the History section of JEP 444).

Aside from observability, the other issue is that GC'ing a thread that 
has not terminated will be very surprising to some developers. In many 
cases it will be transparent but there are cases where it is more 
nuanced and can be observed in advanced usages. Finalization is one 
topic. Another is Cleaner actions that may run while a resource is in an 
inconsistent state.

The summary is that the behavior you observe in JDK 21/22/23 is the 
expected behavior. Virtual threads started directly with the Thread API 
will be kept strongly reachable until they terminate. The thread dump 
and other observability support can be used to identify "abandoned" 
threads.  This project has left the door open to the possibility of 
introducing some notion of "ephemeral threads" in the future. It would 
require quite a bit of exploration in several areas, would have to be 
opt-in, and would also require Finalization to be removed before 
introducing anything.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240709/84dd9366/attachment.htm>