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

[Ron Pressler]

> On 1 Aug 2024, at 00:15, Robert Engels <robaho at icloud.com> wrote:
> 
> Here we are talking about something even worse - no exception up the stack - just object references vanishing - regardless of locks, stack-levels, etc.

Java objects always “just vanish” without any exceptions, and I’m not sure what locks and stack levels have to do with it. If a thread is provably stuck forever *and* you’re not able to observe that it’s stuck forever, then you’re not able to know anything about it whether or not it is collected (the assumption that the objects that are logically referenced by the thread’s stack will not be collected until the thread is collected is not true). If you are interested in observe the thread, and so it won’t be collected as long as you’re interested in observing it.

I honestly don’t understand what your complaint is. Those who are interested in observing all threads will not have anything collected until the threads terminate, and those who may have millions of threads and aren’t interested in observing each and every one of them may want to reuse the memory of stuck threads. There is no right and wrong here, and people will have the option to choose.

> 
> Imagine an auxiliary thread that had a soft/weak reference to A and and a reference queue. It would see A reference added to the code - but no review of any logs, etc. would allow the developer to determine why it became unreachable.
> 
> The logs would be inconsistent.
> 

All Java object become unreachable once some thread does something that loses a previously strong reference somewhere in the object graph. I don’t know how you’re able to normally track the change in visibility to objects in your logs (even the GCs don’t track that and don’t know when an object becomes unreachable), but this is just how Java works.

— Ron