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

[Ron Pressler]

> On 1 Aug 2024, at 16:55, robert engels <robaho at icloud.com> wrote:
> 
> Unless you are taking exception to my words “auto-cleanup”. I mean this only that the vt and is references are subject to GC. 

All unreachable objects in Java are subject to GC. References in a thread stack are also subject to GC today regardless of whether the thread is reachable, alive, or collected, i.e.:

    void foo() {
        var x = new Object();
        bar();
    }

While bar is executing, x may be collected even though it is still referenced from the stack (and it *will* be collected by most GCs, even when running on platform threads today), because the VM can prove that the thread will never again access x.

Whether the thread itself is collected or not *once you cannot observe it* is an implementation detail, and it matters to Java’s memory management just as any other objects. Java objects are collected not because they vanish or are “done" — in fact, in the mental model allocated objects continue existing forever — but once we can prove that the bytes in the memory holding their state cannot be read — it may be reused. A C programmer may find it strange that the memory of some string has been reused (and so cannot be examined in a heap dump) without it being explicitly deallocated, but that’s just how Java works.

If you’re wondering about use-cases, think about infinite (or very learge) streams in Java today. Infinite streams obviously don’t eagerly generate all their elements.They generate more elements when they’re asked, and consumers don’t necessarily tell them when they’re done asking. Now imagine you want to elements to be produced by a thread, and that you create 1M such streams per second.

In any event, I think this subject has been discussed as long as it could be without any further experience reports.

— Ron