I wanted to add another ’user’ vote for Ephemeral threads.
We are experimenting with custom schedulers (thread pools) for VT, which is
what I suspect Alex’s point was about in the first place.
Victor I think you are almost making the same observation when you said:
> Theoretically, you could make a rather solid argument that a VirtualThread is
> never ephemeral, but a Continuation could be?
>
So in someways (more powerful than Continuation) I would like to have VT have
some semantics relaxed for custom VT schedulers.
Additional questions do arise for example: we don’t allow our users to use
try….
We provide a replacement API that deals with additional semantics.
We also have a concept of cancellationScopes (Seems there might be some
intersection with what Alan referred to when he mentioned ScopedTasks)
For example:
someCollection.apar.map { …. }
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.
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….
> On Jan 9, 2026, at 8:03 AM, Viktor Klang <[email protected]> wrote:
>
> Hi Alex,
>
> 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?!".
>
> 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.
>
> 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.
>
> Theoretically, you could make a rather solid argument that a VirtualThread is
> never ephemeral, but a Continuation could be?
>
> 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.
>
> 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.
>
>
>
> On 2026-01-09 10:33, Alan Bateman wrote:
>> On 08/01/2026 17:48, Alex Miller wrote:
>>>
>>> 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.
>>
>> 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.
>>
>> 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.
>>
>> -Alan
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> --
> Cheers,
> √
>
>
> Viktor Klang
> Software Architect, Java Platform Group
> Oracle
