Virtual thread memory leak because TrackingRootContainer keeps threads

[Robert Engels]

As I mentioned, you can’t just make the threads “disappear”. The only option would be for the read() to terminate with an interrupted exception, or UnsatisfiableError (or the like), but the thread would continue - unless the exception went all the way up the stack to cause the thread termination - which is already clearly defined.

> On Jul 2, 2024, at 11:16 AM, Brian S O'Neill <bronee at gmail.com> wrote:
> 
> But I guess you'd need a reference to the Thread in order to stop it, and so it wouldn't be GC'd anyhow. The bigger problem might be ThreadGroups, since all threads belong to one. To be GC'd, all threads in the group would also need to be gone.
> 
> On 2024-07-02 09:12 AM, Brian S O'Neill wrote:
>> 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