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