<html aria-label="message body"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div>I wanted to add another ’user’ vote for Ephemeral threads.</div><div><br></div><div>We are experimenting with custom schedulers (thread pools) for VT, which is what I suspect Alex’s point was about in the first place.</div><div>Victor I think you are almost making the same observation when you said:</div><div><blockquote type="cite"><p>Theoretically, you could make a rather solid argument that a VirtualThread is never ephemeral, but a Continuation could be?</p></blockquote></div><div><p>So in someways (more powerful than Continuation) I would like to have VT have some semantics relaxed for custom VT schedulers.</p><p>Additional questions do arise for example: we don’t allow our users to use try…. </p><p>We provide a replacement API that deals with additional semantics.</p></div><div>We also have a concept of cancellationScopes (Seems there might be some intersection with what Alan referred to when he mentioned ScopedTasks)</div><div><br></div><div>For example:</div><div>someCollection.apar.map { …. }</div><div>Can spin N tasks (Each can get it's VT) If some iteration of the loop throws, we don’t need to rest of the code to run, it’s costly.</div><div>If the task are not actively mounted but previously started and are waiting… (in our case it’s LockSupport.park) we just want to drop that entire queue and everything around it….</div><div><br></div><div><br></div><div><br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Jan 9, 2026, at 8:03 AM, Viktor Klang <viktor.klang@oracle.com> wrote:</div><br class="Apple-interchange-newline"><div>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div><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”—said: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><div style="line-height: 1.38; margin-top: 0pt; margin-bottom: 0pt;"><span style="font-size: 11pt; font-family: Arial, sans-serif; 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></div>
</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>
</div>
</div></blockquote></div><br></div></body></html>