<div dir="ltr">Hi,<br><br>I would like to present my case for ephemeral VT.<br>I have a websocket, the websocket has a correlated blocking queue, there is a virtual thread which reads from the queue and writes to the websocket session.<br>When session is closed, I remove blocking queue from global concurrent hash map<br>But I have to<br>- keep reference to VT<br>- interrupt VT on-session-closed<br>It is similar to  C++ destructor.<br>If I can rely on GC, I will just remove blocking queue reference and everything will happen automatically.<br><br>Regards,<div>Michal Domagala<br><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">sob., 10 sty 2026 o 13:20 Andrew Haley <<a href="mailto:aph@redhat.com">aph@redhat.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">On 09/01/2026 13:03, Viktor Klang wrote:<br>
>   From my perspective, the big issue with ephemerality of VTs is that it<br>
> easily leads to problems where resources leak with no trace of who<br>
> leaked it—which tends to be rather nightmarish to deal with once they<br>
> pop up in production—"Hey, why is this semaphore unbalanced?!".<br>
<br>
I don't understand what scenario you're talking about.<br>
<br>
How, exactly, would you make a thread unreachable? It can't be on any <br>
reachable queue, so it isn't waiting on a timer or I/O. It can't be <br>
running, because the it's trivially reachable.<br>
<br>
Maybe it's waiting on some kind of semaphore that has become <br>
unreachable. In that case, the thread cannot make any progress. It makes <br>
no difference whether you GC it or not. The native resources it holds <br>
will never be released. Semantically, an unreachable thread is not a <br>
thing: it has no properties.<br>
<br>
Therefore, any thread that is unreachable may be GC'd, surely.<br>
<br>
I guess I may be missing some way that an unreachable thread is <br>
observable? If so, what is it?<br>
<br>
-- <br>
Andrew Haley  (he/him)<br>
Java Platform Lead Engineer<br>
<a href="https://keybase.io/andrewhaley" rel="noreferrer" target="_blank">https://keybase.io/andrewhaley</a><br>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671<br>
<br>
</blockquote></div>