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

[robert engels]

Ron,

Given the following code 4 running in a VT:

A a = new VeryLargeObjectWithFinalizer();

try {
    queue.take();
} finally {
   a.doSonething();
}

What in the Java spec would allow a to be reclaimed without doSomething() being called?

If a can’t be reclaimed then the reclaiming on VT in this case is pointless. 

> On Jul 31, 2024, at 10:54 AM, Ron Pressler <ron.pressler at oracle.com> wrote:
> 
> 
> 
>> On 31 Jul 2024, at 15:24, Robert Engels <robaho at icloud.com> wrote:
>> 
>> 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.
> 
> There is no automatic termination or vanishing of anything. A virtual thread that cannot possibly ever have any effect and _already_ cannot be accessed or observed in any way, may or may not have its memory reclaimed, same as for all Java objects.
> 
>> 
>> It will be an absolute nightmare to audit any system that relies on this.
> 
> 
> Every Java system relies on this already, as this is how Java’s GCs have always worked.
> 
> 
>> 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.
> 
> There is nothing about queues or anything special here. No new kind of vanishing or cleanup. Just about the GC reclaiming and reusing the heap bytes of objects that have already vanished. If a thread can be observed, then its memory won't be reclaimed. If it cannot, then whether or not the bytes are reused is an internal implementation detail, just as it is for any Java object.
> 
> — Ron
> 
>