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

[robert engels]

This analysis is incorrect. The guarantees about program order say that ‘a’ must be alive OR the finally block must execute. There is no gray area here. This MUST hold. 

You don’t even need to references GC roots - the specification considers reachability from instance of Thread. A VirtualThread extends Thread so proper OO means it must act as a Thread for all behaviors of Thread. 

> On Jul 31, 2024, at 1:29 PM, Michal Domagala <outsider404 at gmail.com> wrote:
> 
> 
> Documentation says: "The finally block always executes when the try block exits"
> Not "The finally block always executes"
> 
> I think there are 3 areas to seek an answer about correct VT behavior.
> 
> First is general, "sky-level" rules. GC rule says that "what is unreferenced and is not GC root, is collectable". The rule says that VT should be collectable, but many may contest that the rule - as very generic - is not applicable for blocked VT. But the rule works: blocked VT is successfully GC-able, if only observability is off.
> 
> Second is habits. I agree that there is a habit that "finally block" is always executed. But maybe it is just a habit? I think VT GC case in something fresh and cannot be matched to existing experience, but if do "kill -s SIGTERM", which is more cooperative than SIGKILL or unplug power, "finally block" is not executed
>  
> Third is common sense. If something is unreachable, better reclaim resources and pray it works than have a memory leak and countdown to OOM.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240731/270cd332/attachment.htm>