<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi,</div><div dir="ltr"><br></div><div dir="ltr">My issue is accepted as <a href="https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8336061" target="_blank">Bug ID: JDK-8336061 Virtual threads cannot be GC'ed before they terminate (java.com)</a> and solved as documentation defect.<br><div><br></div><div>Still one issue is not clear to me. Is VT strongly referenced because being blocked and GC'ed is not useful or is problematic to implement?</div><div><br></div><div>There were voices in discussion that VT GC  is surprising for developers. For that reason I showed my case. I wanted to present that "closing" blocking queue by nullifying and GC does not need synchronization. Unsynchronized code is less prone to errors than code with synchronization.</div><div><br></div><div>But there are voices that garbage collection "alive" VT is problematic: "Finalization is one topic. Another is Cleaner actions that may run while a resource is in an inconsistent state." I don't know this area so I can't deny it.</div><div><br></div><div>I checked that the blocked task created by <span style="font-family:"JetBrains Mono",monospace;color:rgb(0,0,0)">Executors</span><span style="font-family:"JetBrains Mono",monospace;color:rgb(8,8,8)">.</span><span style="font-family:"JetBrains Mono",monospace;color:rgb(8,8,8);font-style:italic">newVirtualThreadPerTaskExecutor</span><span style="font-family:"JetBrains Mono",monospace;color:rgb(8,8,8)">().submit()</span> is GCed. Does it mean that:</div><div><br>1) <span style="font-family:"JetBrains Mono",monospace;color:rgb(0,0,0)">Executors</span><span style="font-family:"JetBrains Mono",monospace;color:rgb(8,8,8)">.</span><span style="font-family:"JetBrains Mono",monospace;color:rgb(8,8,8);font-style:italic">newVirtualThreadPerTaskExecutor</span><span style="font-family:"JetBrains Mono",monospace;color:rgb(8,8,8)">().submit() </span>does not create VT?<br>2) VT created by Executors API is different from that created by Thread API and can GCed without problem with finalization and Cleaner action?</div><div>3) VT created by Executors API is has the same problem as created by Thread API and in future all VT will be strongly referenced?</div><div>4) Is it a fairy tale that VT GC is problematic?</div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">śr., 10 lip 2024 o 16:54 robert engels <<a href="mailto:robaho@icloud.com" target="_blank">robaho@icloud.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">Also, my original point were about observability (monitoring, detecting hung threads, lifecycle events, etc). I think that is the same as what Alan was referring too. <br>
<br>
> On Jul 10, 2024, at 8:15 AM, Ron Pressler <<a href="mailto:ron.pressler@oracle.com" target="_blank">ron.pressler@oracle.com</a>> wrote:<br>
> <br>
> <br>
> <br>
>> On 9 Jul 2024, at 17:11, robert engels <<a href="mailto:robaho@icloud.com" target="_blank">robaho@icloud.com</a>> wrote:<br>
>> <br>
>> With a closable queue you can have natural synchronization so that all submitted items can be acked then any further reads will cause a “queue closed exception” causing the reader to terminate.<br>
>> <br>
>> It is very similar in design to an executor service.<br>
> <br>
> You are talking about something quite different from the subject of this discussion. You’re talking about a mechanism for *terminating* threads. The discussion is about collecting the effectively meaningless bytes of “effectively dead” *unterminated* threads. The only impact of that is on heap usage and observability, not on any functional thread behaviour. These two things are orthogonal.<br>
> <br>
> You may ask what the pros and cons of collecting “effectively dead” threads are, given that there is no functional difference whether you do or don’t, but I’ll leave that for a separate discussion.<br>
> <br>
> — Ron<br>
</blockquote></div>