<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Weak Refs don’t fully work - at least not the with the standard queus.<div class=""><br class=""></div><div class="">if you do</div><div class=""><br class=""></div><div class="">weakref.get().take()</div><div class=""><br class=""></div><div class="">you’ve created a strong reference in during the duration of the take() if the VT is a GC root - which I thought they were until this discussion. But it sounds like they are only considered a GC root if they can ever be Runnable again - and that the system is going to try and determine that the VT is never runnable, so a take() will be magically ended and every reference the VT thread had to any object is cleared and things just get cleaned up. I assume finalizers and cleaners will still run for all affected objects, including the queue object itself.</div><div class=""><br class=""></div><div class="">It’s fine and workable, but I think it is magic that Java doesn’t need. Clearly the Loom teams understands how they would implement it (I admit I have no idea - I think about it and it feels very complex to try and implement without special cases some types of VT blocks).</div><div class=""><br class=""></div><div class="">Having PT be GC roots and not having VT threads be GC roots feels wrong to me, but I am having a hard time fully articulating why.</div><div class=""><br class=""></div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 3, 2024, at 12:28 PM, Davor Hrg <<a href="mailto:hrgdavor@gmail.com" class="">hrgdavor@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class="">I am likely misunderstanding. Could weak reference to VT be ok, to be able to enumerate from inside the app? And gc to do its thing</div><div dir="auto" class=""><br class=""></div><div dir="auto" class=""><br class=""><br class=""><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Wed, 3 Jul 2024, 19:24 Attila Kelemen, <<a href="mailto:attila.kelemen85@gmail.com" class="">attila.kelemen85@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="">Maybe Ron will prove me wrong, but I never felt that the design of the JEP was meant to make VT appear as PT in all aspects. In fact, what the JEP is usually about is that it equates VT with tasks submitted to an executor. And in that case, VT being a GC root is a strange thing. Though I think either case is unlikely to make a difference in practice.</div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">robert engels <<a href="mailto:rengels@ix.netcom.com" target="_blank" rel="noreferrer" class="">rengels@ix.netcom.com</a>> ezt írta (időpont: 2024. júl. 3., Sze, 16:58):<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">I understand, but with a PT thread being a GC, and methods like Thread.enumerate() is was never possibly - and a “service” could always find the “blocked” threads and interrupt them.<div class=""><br class=""></div><div class="">If VT are not findable (or optionally findable), I think it is a breaking change which goes against the JEP design for virtual threads, and it is going to lead to two different types of patterns for queue handling based on the thread types involved - I think this is a very bad idea.<br class=""><div class=""><br class=""></div></div></div></blockquote></div></div>
</blockquote></div></div></div>
</div></blockquote></div><br class=""></div></body></html>