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

[Ron Pressler]

> On 1 Aug 2024, at 20:04, Robert Engels <robaho at icloud.com> wrote:
> 
> 
> I find memory leaks - or lack there of - a decent check of correctness. With this VT change, that will no longer be the case.

If you find memory leaks an aid to debugging, by all means track all of your threads.

> 
> I also don’t like reviewing a piece of code - consumer() in this case - and having to determine if it is correct based on a system property value. This seems against Java’s explicitness (although I realize some system properties already alter behavior greatly).

It is not. Whether and when objects are collected is also subject to GC selection. One of the GCs in the JDK never collects any object.

But it seems to me that all you’re doing is using an implementation detail as an aid to debugging the code, and that’s fine.


> 
> As an aside, based on your previous comments, it is curious that the objects are not collected in A. It is in the same state as B - the system knows that queue.take() can never advance - so if the references are not being held by stack entries then they should be collected, right - regardless that a Thread is a GC root?

Let’s forget about roots. Roots are an implementation detail of the GC, and even the same GC can treat different objects as roots or not depending on the type of the collection. What matters is whether or not an object is reachable. Well, platform threads do happen to be roots and that’s why they’re always considered reachable, but that’s not the point. What matters to the purpose of understanding the behaviour is that all platform threads are always considered reachable.

Now, if a thread is reachable, it is much harder to prove that it is, indeed, stuck forever (e.g. you can obtain a reference to it and interrupt it). The simple proof that a thread is stuck forever is that it is blocked unreachable, because if it is unreachable it is neither currently scheduled nor can it ever be unblocked (or interrupted) because to unblock (or interrupt) a thread, you need a reference to it.

Because a platform thread is reachable, the VM cannot prove that it’s stuck forever, and so it assumes it could continue, and if it can continue, then it may access certain references on the stack, so they’ll be considered live.

— Ron