Ephemeral threads

[Michal Domagala]

Hi,

I would like to present my case for ephemeral VT.
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.
When session is closed, I remove blocking queue from global concurrent hash
map
But I have to
- keep reference to VT
- interrupt VT on-session-closed
It is similar to  C++ destructor.
If I can rely on GC, I will just remove blocking queue reference and
everything will happen automatically.

Regards,
Michal Domagala


sob., 10 sty 2026 o 13:20 Andrew Haley <aph at redhat.com> napisał(a):

> On 09/01/2026 13:03, Viktor Klang wrote:
> >   From my perspective, the big issue with ephemerality of VTs is that it
> > easily leads to problems where resources leak with no trace of who
> > leaked it—which tends to be rather nightmarish to deal with once they
> > pop up in production—"Hey, why is this semaphore unbalanced?!".
>
> I don't understand what scenario you're talking about.
>
> How, exactly, would you make a thread unreachable? It can't be on any
> reachable queue, so it isn't waiting on a timer or I/O. It can't be
> running, because the it's trivially reachable.
>
> Maybe it's waiting on some kind of semaphore that has become
> unreachable. In that case, the thread cannot make any progress. It makes
> no difference whether you GC it or not. The native resources it holds
> will never be released. Semantically, an unreachable thread is not a
> thing: it has no properties.
>
> Therefore, any thread that is unreachable may be GC'd, surely.
>
> I guess I may be missing some way that an unreachable thread is
> observable? If so, what is it?
>
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260110/93200b0d/attachment.htm>