Virtual thread memory leak because TrackingRootContainer keeps threads

[Brian S O'Neill]

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