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

[Robert Engels]

“Thread leak” is real, but I don’t think the solution is to try add auto-cleanup. It almost always points to a poor or overly complicated design. I wrote a few samples in a branch using the Closable Queue https://github.com/robaho/closablequeue/blob/sample/src/main/java/robaho/queue/sample
with the “original” being one that was relying on the auto-cleanup provided by someone else, and these were to demonstrate what I think is a better, simpler, design.

The techniques mimic  https://go101.org/article/channel-closing.html <https://go101.org/article/channel-closing.html> and the proper use of channels. Go’s concurrency design is specifically to not share data, and is closer to CSP, so the heavy use of channels (closable queues) as communication between threads.

Thread leak (or deadlock in a fixed pool environment) was an issue long before virtual threads. Virtual threads if anything will surface the bad code more quickly - as long as the monitoring tools make the VT leaks obvious. Even if this is implemented, most likely it won’t help, as if they have a leak in this case, they will probably leak the producer/queue reference, so the VT won’t be able to be collected anyway.

I truly believe that freeing the resources as if the thread exited up the stack even though it didn’t is going to cause to a ton of problems - making debugging much harder. Yes, you may not have a resource leak, but you have probably masked the underlying problem, and the code is not correct. At least with a resource leak, it is easy to detect that it is happening and why.

The auto-cleanup might solve this one particular issue but it won’t protect people from writing bad code - if anything this allows them to be less diligent and you are only going to make the problems harder to solve.

> On Aug 1, 2024, at 9:39 AM, Ron Pressler <ron.pressler at oracle.com> wrote:
> 
> 
> 
>> On 1 Aug 2024, at 11:08, robert engels <robaho at icloud.com> wrote:
>> 
>> And actually it is even worse than that , because if you are relying on the differing behavior between virtual threads and platform threads to avoid resource leaks in your application, god help you. 
> 
> I don’t know how you can use virtual threads and *not* rely on their different resource (and especially memory) consumption from platform threads. After all, virtual threads are a feature that allows the creation of many threads, and that is accomplished through different memory management. In other words, you use virtual threads *because* they use memory differently from platform threads (although, as I mentioned in other responses, I think you’re making some incorrect assumptions about how threads, including platform threads retain references, and it is not true that a reference that is logically on the stack is always retained).
> 
> “Thread leak” is a real problem in languages that allow creating lots of lightweight threads, such as Go.
> 
> — Ron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240801/48e47595/attachment.htm>