<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">More specifically, it is that ‘a’ cannot be reclaimed and the finally not run. This breaks the program ordering guarantees as related to retainability. </div><div dir="ltr"><br><blockquote type="cite">On Jul 31, 2024, at 11:59 AM, Pedro Lamarão <pedro.lamarao@prodist.com.br> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr">This seems to me a simple contradiction of requirements.<div>One cannot require that this program behaves as stated, that this thread cannot proceed, and then require that the finally block runs.</div><div>Either the thread can proceed, or it cannot.</div><div>If it cannot, requiring that this thread runs code is nonsensical to me.</div><div>Perhaps one should just revise one's queue design and/or implementation to avoid becoming "impossible" instead.</div><div>The fact the queue in question allows for "zombie platform thread" does not seem a feature to me.</div><div>"zombie platform threads" is just a resource leak in a system with no automatic resource reclamation.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em qua., 31 de jul. de 2024 às 13:53, Robert Engels <<a href="mailto:rengels@ix.netcom.com" target="_blank">rengels@ix.netcom.com</a>> escreveu:<br></div><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"><div dir="ltr"></div><div dir="ltr">More importantly the reason to reclaim the VT would be to release its stack memory I assume. So then there are no rererences to a which would means would get reclaimed without running the finally. This is invalid. </div><div dir="ltr"><br><blockquote type="cite">On Jul 31, 2024, at 11:50 AM, robert engels <<a href="mailto:robaho@icloud.com" target="_blank">robaho@icloud.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"></div><div dir="ltr">Correct and that is valid. Reclaiming a without running the finally block is invalid. </div><div dir="ltr"><br><blockquote type="cite">On Jul 31, 2024, at 11:44 AM, Pedro Lamarão <<a href="mailto:pedro.lamarao@prodist.com.br" target="_blank">pedro.lamarao@prodist.com.br</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr">if take cannot possibly proceed, then the body of the finally block will never, ever, run, and all memory involved has just leaked.<div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em qua., 31 de jul. de 2024 às 13:41, robert engels <<a href="mailto:robaho@icloud.com" target="_blank">robaho@icloud.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">To clarify, there is no other reference to the queue so take() cannot proceed <br>
<br>
> On Jul 31, 2024, at 11:36 AM, robert engels <<a href="mailto:robaho@icloud.com" target="_blank">robaho@icloud.com</a>> wrote:<br>
> <br>
> Ron,<br>
> <br>
> Given the following code 4 running in a VT:<br>
> <br>
> A a = new VeryLargeObjectWithFinalizer();<br>
> <br>
> try {<br>
> queue.take();<br>
> } finally {<br>
> a.doSonething();<br>
> }<br>
> <br>
> What in the Java spec would allow a to be reclaimed without doSomething() being called?<br>
> <br>
> If a can’t be reclaimed then the reclaiming on VT in this case is pointless.<br>
> <br>
>> On Jul 31, 2024, at 10:54 AM, Ron Pressler <<a href="mailto:ron.pressler@oracle.com" target="_blank">ron.pressler@oracle.com</a>> wrote:<br>
>> <br>
>> <br>
>> <br>
>>>> On 31 Jul 2024, at 15:24, Robert Engels <<a href="mailto:robaho@icloud.com" target="_blank">robaho@icloud.com</a>> wrote:<br>
>>> <br>
>>> The purpose of the queue implementation is so that a VT is not left running - hung on a queue that will never receive a value, and the reader has a way of cleaning up cleanly if needed.<br>
>>> <br>
>>> I still don’t see how automatically “terminating/vanishing” the reading thread when it can’t make progress will work.<br>
>> <br>
>> There is no automatic termination or vanishing of anything. A virtual thread that cannot possibly ever have any effect and _already_ cannot be accessed or observed in any way, may or may not have its memory reclaimed, same as for all Java objects.<br>
>> <br>
>>> <br>
>>> It will be an absolute nightmare to audit any system that relies on this.<br>
>> <br>
>> <br>
>> Every Java system relies on this already, as this is how Java’s GCs have always worked.<br>
>> <br>
>> <br>
>>> I confess I am not a JDK engineer but without special casing how can the runtime know this - a special reference type for queue classes only? I.e. the blocked reader is using a WeakReference internally? Today, circular references are not circular in the context of a Thread GC root.<br>
>> <br>
>> There is nothing about queues or anything special here. No new kind of vanishing or cleanup. Just about the GC reclaiming and reusing the heap bytes of objects that have already vanished. If a thread can be observed, then its memory won't be reclaimed. If it cannot, then whether or not the bytes are reused is an internal implementation detail, just as it is for any Java object.<br>
>> <br>
>> — Ron<br>
>> <br>
>> <br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Pedro Lamarão</div></div></div></div>
</div></blockquote></div></blockquote></div></blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Pedro Lamarão</div></div></div>
</div>
</div></blockquote></body></html>