Ephemeral threads

[Dmitry Zaslavsky]

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 <viktor.klang at oracle.com> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260109/79bdd60f/attachment.htm>