Ephemeral threads

[Michal Domagala]

Excuse me,
it is not clear to me if my post is unanswered because it is reply for
wrong branch ot topic is exhausted and there is nothing to add

pt., 6 lut 2026 o 12:08 Viktor Klang <viktor.klang at oracle.com> napisał(a):

> 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/20260217/ea0c732a/attachment.htm>