<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hi Alex,<br>
<br>
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?!".<br>
<br>
On one hand, there's a bit of a 30-year old semantical expectation
that "threads are GC roots"—which allows things like daemon
threads—what is the expectation of daemon ephemeral virtual
threads? Interestingly, daemonicity is sort of "half-ephemeral in
the global scale" in the sense that only non-daemonic threads
prevents the exit of the runtime.</p>
<p>On the other, the ephemerality feature is intrinsically related
to the notion of reachability, which is a runtime determination
only loosely related to the code itself—as an example, people tend
to be surprised that an object instance can be garbage-collected
(i.e. deemed unreachable) while a method on it is still being
executed.</p>
<p>Theoretically, you could make a rather solid argument that a
VirtualThread is never ephemeral, but a Continuation could be?</p>
<p>Another complicating factor is that the code to be executed does
not know whether it executes on an ephemeral VirtualThread or
not——as the general case for Thread::run() calls into third-party
logic, considering that the Java standard library, to a developer
not working on the JDK, is third-party logic to that developer. </p>
<p>Should all developers, always, ensure that the code they write is
correct under the presumption that the evaluator (a Thread) is
ephemeral? That carries the implication that all tests should
always be executed by ephemeral virtual threads—and they should be
run N (what would be a reasonable value of N here?) times, because
timing of unreachability may change observable effects. I,
personally, think that price is too steep to pay for this feature.<br>
<br>
<br>
</p>
<div class="moz-cite-prefix">On 2026-01-09 10:33, Alan Bateman
wrote:<br>
</div>
<blockquote type="cite" cite="mid:518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com">
<div class="moz-cite-prefix">On 08/01/2026 17:48, Alex Miller
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com">
<div dir="ltr"><span id="gmail-docs-internal-guid-dcdf91a7-7fff-0594-ea29-4439c3c32cd1"><br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">Given
where things stood at Java 21 time and where we are now,
can we move the idea of ephemeral thread support
forward? This is very important to us and we are happy
to get involved with the process and contribute if that
would be helpful.</span></p>
</span></div>
</blockquote>
<br>
The possibility of GC'ing a started thread before it terminates is
a scary topic. It interacts with many areas and gets really scary
once you bring phantom refs, cleaners, and finalizers into the
discussion.<br>
<br>
For these so-called "forgotten sender" and "abandoned receiver"
cases then it might be more interesting to see how they could be
work with structured concurrency. Right now, the first API is
focused on fan-out scenarios but in time we would like to have it
work with channel like constructs too. I suspect this will be
closer to what you are interested in.<br>
<br>
-Alan<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
<pre class="moz-signature" cols="72">--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle</pre>
</body>
</html>