<div dir="ltr"><div dir="ltr"><div dir="ltr">First, today I successfully reported the issue to <a href="https://bugreport.java.com">https://bugreport.java.com</a>. I do not need help or assistance anymore.</div><div dir="ltr"><br></div><div>Second, indeed, technically speaking, it is a memory leak issue, not GC root issue. Unfortunately, I do not know any documentation which declares that memory leaks in JDK are not allowed.</div><div>However, the issue is strictly related to JEP 444, which directly explains how VTs are reclaimed by GC. Including an example. I'm pretty sure that the memory leak bug is caused by lack of awareness that VTs are not GC root.</div><div><br></div><div>Continuing technical speaking, GC never MUST reclaim any particular object. GC MUST separate used and unused objects and MAY reclaim memory taken by unused objects.<br>It means the contract "...the [virtual] thread can be garbage collected" is broken because blocked VT can NOT be garbage collected.</div><div><br></div><div>Nevertheless, I'm satisfied because thread goal - report the issue to Oracle - is done. Thanks to any thread participant for taking effort</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">wt., 9 lip 2024 o 00:02 Brian S O'Neill <<a href="mailto:bronee@gmail.com">bronee@gmail.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">The exact phrase in JEP 444 is, "Unlike platform thread stacks, virtual <br>
thread stacks are not GC roots."  GC roots also include static fields, <br>
but the tracked VT is only indirectly referenced by a static field, via <br>
a map object. So technically speaking, JEP 444 and JDK 21 are in agreement.<br>
<br>
Also note that JEP 444 says, "...the [virtual] thread can be garbage <br>
collected"  It doesn't say that the virtual thread MUST be garbage <br>
collected.<br>
<br>
<br>
On 2024-07-08 02:12 PM, Michal Domagala wrote:<br>
> Hi<br>
> <br>
> As a thread author, I would like to say I opened the thread because I <br>
> could not report a memory leak as a bug. Page <br>
> <a href="https://bugreport.java.com/bugreport/submit_start" rel="noreferrer" target="_blank">https://bugreport.java.com/bugreport/submit_start</a> <br>
> <<a href="https://urldefense.com/v3/__https://bugreport.java.com/bugreport/submit_start__;!!ACWV5N9M2RV99hQ!O3-6Y8rB_Q3TnOXLeIa2WkhSm-X8hYgCkqwGAG4EqpVKaFgdKdh4kpH4juXWBBVbkBbMxFZDjRsTawE7Yeih$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://bugreport.java.com/bugreport/submit_start__;!!ACWV5N9M2RV99hQ!O3-6Y8rB_Q3TnOXLeIa2WkhSm-X8hYgCkqwGAG4EqpVKaFgdKdh4kpH4juXWBBVbkBbMxFZDjRsTawE7Yeih$</a>>  does not work.<br>
> <br>
> In my understanding JEP 444 is finished and delivered in JDK 21. Any <br>
> deviation between JEP 444 and JDK 21 is a bug.<br>
> I hoped somebody will say "OMG" and start fixing procedure. But it seems <br>
> to me discussion concerns on JEP 444 - good or bad decision was taken.<br>
> <br>
> Personally, I have high confidence in the written word. Written word <br>
> convinced me that VT is GC'ed. It's very interesting to see other <br>
> opinions, but in my understanding the time is out of joint and seek for <br>
> help to set it right<br>
> <br>
</blockquote></div>