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

[Brian S O'Neill]

I think there's also the question of efficiency. If every new VT needs 
to be registered, then this adds a bit of overhead and makes them 
slightly less useful for running short-lived tasks.

On 2024-07-10 12:56 PM, Michal Domagala wrote:
> Hi,
> 
> My issue is accepted as Bug ID: JDK-8336061 Virtual threads cannot be 
> GC'ed before they terminate (java.com) 
> <https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8336061> and 
> solved as documentation defect.
> 
> Still one issue is not clear to me. Is VT strongly referenced because 
> being blocked and GC'ed is not useful or is problematic to implement?
> 
> There were voices in discussion that VT GC  is surprising for 
> developers. For that reason I showed my case. I wanted to present that 
> "closing" blocking queue by nullifying and GC does not need 
> synchronization. Unsynchronized code is less prone to errors than code 
> with synchronization.
> 
> But there are voices that garbage collection "alive" VT is problematic: 
> "Finalization is one topic. Another is Cleaner actions that may run 
> while a resource is in an inconsistent state." I don't know this area so 
> I can't deny it.
> 
> I checked that the blocked task created by 
> Executors.newVirtualThreadPerTaskExecutor().submit() is GCed. Does it 
> mean that:
> 
> 1) Executors.newVirtualThreadPerTaskExecutor().submit() does not create VT?
> 2) VT created by Executors API is different from that created by Thread 
> API and can GCed without problem with finalization and Cleaner action?
> 3) VT created by Executors API is has the same problem as created by 
> Thread API and in future all VT will be strongly referenced?
> 4) Is it a fairy tale that VT GC is problematic?
>