Virtual thread memory leak because TrackingRootContainer keeps threads

Brian S O'Neill bronee at gmail.com
Tue Jul 2 16:12:50 UTC 2024


Before Thread.stop was disabled, a platform thread could never be stuck 
in an unbreakable wait. It might be possible to allow platform threads 
to be GC'd when it's impossible to be woken up, but it wouldn't work 
when the blocking is in native code.

On 2024-07-02 09:01 AM, Pedro Lamarão wrote:
> Em seg., 1 de jul. de 2024 às 21:02, Brian S O'Neill <bronee at gmail.com 
> <mailto:bronee at gmail.com>> escreveu:
> 
>     If you depended on virtual threads being GC'd when blocked with a real
>     infinite timeout, then switching to platform threads would introduce a
>     memory leak that didn't exist before. Ideally, the two thread types
>     should be interchangeable.
> 
> 
> But what about an "impossible" wait?
> A thread in a pseudo-infinite wait will wake eventually, and the 
> platform cannot know if this was intentional or not.
> But a thread waiting on a blocking queue whose only reference is the 
> thread itself will never wake, since there is no one to insert into the 
> queue.
> 
> --
> Pedro Lamarão


More information about the loom-dev mailing list