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

[Robert Engels]

The purpose of the queue implementation is so that a VT is not left running - hung on a queue that will never receive a value, and the reader has a way of cleaning up cleanly if needed.

I still don’t see how automatically “terminating/vanishing” the reading thread when it can’t make progress will work.

It will be an absolute nightmare to audit any system that relies on this.

I confess I am not a JDK engineer but without special casing how can the runtime know this - a special reference type for queue classes only? I.e. the blocked reader is using a WeakReference internally? Today, circular references are not circular in the context of a Thread GC root.

You either have discoverability and monitorability of the execution threads or you don’t. I cited the areas of the Java specification that I believe govern this in terms of reachability, and I don’t think having them disappear is valid. It would be an incorrect subclassing of Thread to change this behavior in VirtualThread.

> On Jul 31, 2024, at 9:10 AM, Ron Pressler <ron.pressler at oracle.com> wrote:
> 
> 
> 
>> On 25 Jul 2024, at 16:17, Robert Engels <robaho at icloud.com> wrote:
>> 
>> I have created a very simple unbounded FIFO queue designed for use with virtual threads to better ensure thread clean-up without the reliance of automatic clean-up of VTs.
>> 
>> You can review the project here https://github.com/robaho/closablequeue
> 
> Just to be clear, there is never any kind of “automatic clean-up” of virtual threads. The bytes holding the state of a virtual thread that cannot possibly continue may or may not be collected before it is terminated, but even if the memory is collected, no cleanup is performed. The only way the collection can be observed is through mechanism that observe the GC’s implementation choices, such as weak references, etc.
> 
> — Ron