<div dir="ltr"><div dir="ltr">Hi<div><br></div><div>As a thread author, I would like to say I opened the thread because I could not report a memory leak as a bug. Page  <a href="https://urldefense.com/v3/__https://bugreport.java.com/bugreport/submit_start__;!!ACWV5N9M2RV99hQ!O3-6Y8rB_Q3TnOXLeIa2WkhSm-X8hYgCkqwGAG4EqpVKaFgdKdh4kpH4juXWBBVbkBbMxFZDjRsTawE7Yeih$" id="m_3164609625677738720x_m_885626347485593257OWAfebd9909-0527-cccb-397c-37aae0d667d0" target="_blank">https://bugreport.java.com/bugreport/submit_start</a>  does not work.</div><div><br></div><div>In my understanding JEP 444 is finished and delivered in JDK 21. Any deviation between JEP 444 and JDK 21 is a bug.<br>I hoped somebody will say "OMG" and start fixing procedure. But it seems to me discussion concerns on JEP 444 - good or bad decision was taken.</div><div><br></div><div>Personally, I have high confidence in the written word. Written word convinced me that VT is GC'ed. It's very interesting to see other opinions, but in my understanding the time is out of joint and seek for help to set it right</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">sob., 6 lip 2024 o 23:32 Ron Pressler <<a href="mailto:ron.pressler@oracle.com" target="_blank">ron.pressler@oracle.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 4 Jul 2024, at 21:34, Brian S O'Neill <<a href="mailto:bronee@gmail.com" target="_blank">bronee@gmail.com</a>> wrote:<br>
> <br>
> On 2024-07-04 11:43 AM, Ron Pressler wrote:<br>
>>> On 3 Jul 2024, at 18:27, robert engels <<a href="mailto:rengels@ix.netcom.com" target="_blank">rengels@ix.netcom.com</a>> wrote:<br>
>>> <br>
>>> I agree 100% - I am fighting that the auto-closing of the queues, clean-up, etc is “unneeded magic”<br>
>> There is no auto-closing, no cleanup, and no magic. If a thread gets stuck in a state where it can never be observed or continued — so if it is NOT waiting on a queue to which something could be enqueued because in that case the thread COULD possibly continue — then whether that thread consumes some inaccessible bytes in memory or not is the same as far as functionality is concerned.<br>
> <br>
> What about the case that that freeing a forever-stuck VT allows more objects to be freed, which then might have cleaning actions? Freeing the stuck VT could create a side effect that would have only occurred when it resumed somehow.<br>
<br>
Whatever differences there may be, you could see similar differences when selecting a different GCs. Any functionality that depends on decisions made by the GC is at the mercy of a particular algorithm that may also change from one JDK release to another for a specific GC (and so probably should be avoided).<br>
<br>
— Ron</blockquote></div>