Ephemeral threads

[Viktor Klang]

I suspect that you are attempting to address something different to what 
Alan had in mind here. I interpret Alan's response to be about 
performance of the grouping, unrelated to whether ephemerality is a 
thing or not.

(The inherent problems linked to ephemerality is discussed at length in 
this thread)

On 2026-02-06 09:40, Michal Domagala wrote:
> I would share my reflections
> 1. All "system" VT, "system" means f.e.created  by 
> Structured Concurrency, automatically ends and never become unreachable
> 2. Only application VT can become unreachable, f.e. when a blocking 
> queue became unreachable
> 3. Every VT is naturally GC-able, because only diagnostic flag 
> trackAllThreads saves unreached VT from release
> 4. Diagnostic is important
> 5. If trackAllThreads use weak reference, it can impact GC, as 
> potentially there can be millions of VT
>
> Maybe it is worth to consider `Thread.ofEphemeral()` tracked by weak 
> reference
> 1. Implementation effort is minimal, there will be two maps of VT 
> instead of one
> 2. Performance effort is zero, because only intentional, application 
> VT can increase GC time (Volenti non fit iniuria)
> 3. Diagnostic still works
>
> Regards
> Michal Domagala
>
> pon., 12 sty 2026 o 13:41 Alan Bateman <alan.bateman at oracle.com> 
> napisał(a):
>
>
>
>     On 10/01/2026 15:55, Alex Miller wrote:
>     > What is the likely future of the trackAllThreads flag?
>     TBD. It's clearly an attractive nuisance right now and setting it to
>     false is specific to the root "thread grouping". There is some
>     performance work required in that area but otherwise I think it
>     needs to
>     be removed.
>
>     -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/20260206/a3d05b4f/attachment.htm>