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

Ron Pressler ron.pressler at oracle.com
Thu Aug 1 09:28:07 UTC 2024



> On 25 Jul 2024, at 14:05, Robert Engels <robaho at icloud.com> wrote:
> 
> 
> I believe section 12.6.1of the language spec covers this. Since it states that an object is reachable if it is reachable from any live thread. Thread “liveness” is not specified based on reachability. Since the spec doesn’t include anything about Thread methods, a Thread must be “live” independent of its reachability (observability from Thread.getAllStackTraces()), otherwise as soon as a Thread is created it it would be unreachable, and any objects it created would be unreachable as well.
> 
> Since a virtual thread inherits from Thread, it must be a Thread, and thus should be governed by the same rules.

What that section says is "A reachable object is any object that can be accessed in any potential continuing computation from any live thread.” A thread that cannot perform any further computation, even potentially, cannot reach any object, therefore its references are irrelevant. The general idea is that an object that could be accessed in the future through strong references will not be collected, but a stuck thread can do nothing at all in the future, let alone access any objects.

Also, while virtual threads and platform threads are both sets of instances of the Thread class, the method Thread.getAllStackTraces() is specified to list all platform threads, not all threads.

Finally, I don’t understand why you’re bothered by any of this. If you’re interested in observing all of your threads, then they will not be collected. Others may use virtual threads in a different way, have millions of them, and would prefer that the memory of those threads that can no longer have any effect would be collected just like any other Java object. You do and will have a choice.

— Ron


More information about the loom-dev mailing list