<div dir="ltr"><div dir="ltr"><div>It is a reason to NOT hold strong reference to VT created by Executor API but NOT a reason to hold strong reference to VT created by Thread API.</div><div>Assume GC'able VT is risky due "Finalization is one topic. Another is Cleaner actions". Assume 99% VT is created by Executor API and 1% is created by Thread API</div><div><br></div><div>If I can afford 99% VT is risky GC'ed, I can afford 100% VT is risky GC'ed and keep system simple without strong reference to any VT</div><div><br></div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Å›r., 10 lip 2024 o 22:57 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">I think there's also the question of efficiency. If every new VT needs <br>
to be registered, then this adds a bit of overhead and makes them <br>
slightly less useful for running short-lived tasks.<br>
<br>
On 2024-07-10 12:56 PM, Michal Domagala wrote:<br>
> Hi,<br>
> <br>
> My issue is accepted as Bug ID: JDK-8336061 Virtual threads cannot be <br>
> GC'ed before they terminate (<a href="http://java.com" rel="noreferrer" target="_blank">java.com</a>) <br>
> <<a href="https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8336061" rel="noreferrer" target="_blank">https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8336061</a>> and <br>
> solved as documentation defect.<br>
> <br>
> Still one issue is not clear to me. Is VT strongly referenced because <br>
> being blocked and GC'ed is not useful or is problematic to implement?<br>
> <br>
> There were voices in discussion that VT GC  is surprising for <br>
> developers. For that reason I showed my case. I wanted to present that <br>
> "closing" blocking queue by nullifying and GC does not need <br>
> synchronization. Unsynchronized code is less prone to errors than code <br>
> with synchronization.<br>
> <br>
> But there are voices that garbage collection "alive" VT is problematic: <br>
> "Finalization is one topic. Another is Cleaner actions that may run <br>
> while a resource is in an inconsistent state." I don't know this area so <br>
> I can't deny it.<br>
> <br>
> I checked that the blocked task created by <br>
> Executors.newVirtualThreadPerTaskExecutor().submit() is GCed. Does it <br>
> mean that:<br>
> <br>
> 1) Executors.newVirtualThreadPerTaskExecutor().submit() does not create VT?<br>
> 2) VT created by Executors API is different from that created by Thread <br>
> API and can GCed without problem with finalization and Cleaner action?<br>
> 3) VT created by Executors API is has the same problem as created by <br>
> Thread API and in future all VT will be strongly referenced?<br>
> 4) Is it a fairy tale that VT GC is problematic?<br>
> <br>
</blockquote></div></div></div>