<p dir="ltr">I don't see objects missing from a heap dump as a problem. I don't think there is any guarantee about that in the JVM spec. In fact, there is no requirement to provide any heap dump. Is there?..</p>
<p dir="ltr">So it really is just about the finalizers being executed or not. I actually think not executing them is better (no guarantees of when they should be executed,  is there?), but maybe there are good reasons to get them executed.</p>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 31 Jul 2024, 23:59 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">The program order - except in a case of abrupt termination - must hold. So having A not be present in a heap dump with the finally block never being executed is a problem. It is breaking the specification on reachability. </div><div dir="ltr"><br></div><div dir="ltr">So change the spec but then you have different behavior if a platform thread is executing the code versus a virtual thread - which would be another nightmare for readability and auditing. </div><div dir="ltr"><br></div><div dir="ltr">I am honestly baffled how this has proceeded so far without someone from the loom team saying - you’re right this would be crazy to do. </div><div dir="ltr"><br></div><div dir="ltr">It has if people are writing systems code with no concern for the application code sitting on top. </div><div dir="ltr"><br><blockquote type="cite">On Jul 31, 2024, at 5:28 PM, Alex Otenko <<a href="mailto:oleksandr.otenko@gmail.com" target="_blank" rel="noreferrer">oleksandr.otenko@gmail.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><p dir="ltr">Like, imagine it is not GCed, but swapped out to /dev/null. Eh? What's the problem with that? We'll swap it back in, when the VT can continue. Deal? :)</p>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 31 Jul 2024, 23:22 Alex Otenko, <<a href="mailto:oleksandr.otenko@gmail.com" target="_blank" rel="noreferrer">oleksandr.otenko@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">I think you may need to revisit heap dump format. It is all best effort to capture JVM state, not actual state, and not true memory representation. Like, the pointers are 64 bit, even if compressed oops are in use, ...</p>
<p dir="ltr">I've seen heap dumps with missing stack traces and missing GC roots. So, no, I don't think we should worry too much about objects that get optimised away.</p>
<p dir="ltr">Side-effecting finalizers bug me. But if you can reclaim memory without executing them, I think it may be fine. After all, that's the behaviour of the program where the object is still alive.</p>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 31 Jul 2024, 23:03 robert engels, <<a href="mailto:robaho@icloud.com" rel="noreferrer noreferrer" target="_blank">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">As a follow-up, even if the heap dump could show the A instance - what about inspection of its fields? Or if you trace its back references what is its root?</div><div dir="ltr"><br></div><div dir="ltr">A virtual thread may not be a GC root, but it’s stack data has to be or every monitoring/analysis technique is broken - and systems will be impossible to audit. </div><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On Jul 31, 2024, at 4:59 PM, robert engels <<a href="mailto:robaho@icloud.com" rel="noreferrer noreferrer noreferrer" target="_blank">robaho@icloud.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><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 <<a href="mailto:oleksandr.otenko@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">oleksandr.otenko@gmail.com</a>> 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" rel="noreferrer noreferrer noreferrer" target="_blank">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" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">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></div></blockquote></div></blockquote></div>
</blockquote></div>
</div></blockquote></div></blockquote></div>