Ephemeral threads

[Viktor Klang]

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"—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/f7b9c227/attachment-0001.htm>