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

[Alex Otenko]

I think your observation about finalizers is important. But without
finalizers - how do you detect that the object is not alive?

More broadly - it is not the object that matters; the code must behave like
if the object were alive. (Think of unwrapped Optionals and Integers)

On Wed, 31 Jul 2024, 22:03 robert engels, <robaho at icloud.com> wrote:

> 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/c03ad874/attachment-0001.htm>