
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">Yes, but it’s a graph, because if A doesn’t have a finalizer but references something that does you face the same problem. </div><div dir="ltr"><br></div><div dir="ltr">I think it will. R very hard to profile / debug applications if this were to come to pass. So I open a profiler and expect to see and instance of A but I don’t, and I don’t see any log message (assume finally block printed something) - am I just suppose to assume… well it was a virtual thread and it “vanished” because it couldn’t make progress. </div><div dir="ltr"><br></div><div dir="ltr">That is ludicrous imo. And also completely unnecessary and against 20 plus years of Java design. </div><div dir="ltr"><br><blockquote type="cite">On Jul 31, 2024, at 4:23 PM, Alex Otenko <oleksandr.otenko@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><p dir="ltr">I think your observation about finalizers is important. But without finalizers - how do you detect that the object is not alive?</p>

<p dir="ltr">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)</p>

<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 31 Jul 2024, 22:03 robert engels, <<a href="mailto:robaho@icloud.com">robaho@icloud.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="ltr"></div><div dir="ltr">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. </div><div dir="ltr"><br></div><div dir="ltr">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. </div><div dir="ltr"><br><blockquote type="cite">On Jul 31, 2024, at 1:29 PM, Michal Domagala <<a href="mailto:outsider404@gmail.com" target="_blank" rel="noreferrer">outsider404@gmail.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><span style="color:rgb(0,0,0);font-size:12.8px"><div dir="ltr">Documentation says: "The finally block always executes when the try block exits"</div><div dir="ltr">Not "The finally block always executes"</div><div dir="ltr"><br></div><div>I think there are 3 areas to seek an answer about correct VT behavior.<br><br></div><div>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.<br><br>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<br> <br></div><div>Third is common sense. If something is unreachable, better reclaim resources and pray it works than have a memory leak and countdown to OOM.</div></span><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"></div></div></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><blockquote type="cite"><div dir="ltr"><div dir="ltr">

</div>

</div></blockquote></div></blockquote></div></div></div></div></div></div>

</div></blockquote></div></blockquote></div>

</div></blockquote></body></html>