<div dir="ltr">I would share my reflections<div>1. All "system" VT, "system" means f.e.created  by Structured Concurrency, automatically ends and never become unreachable</div><div>2. Only application VT can become unreachable, f.e. when a blocking queue became unreachable</div><div>3. Every VT is naturally GC-able, because only diagnostic flag trackAllThreads saves unreached VT from release</div><div>4. Diagnostic is important</div><div>5. If trackAllThreads use weak reference, it can impact GC, as potentially there can be millions of VT</div><div><br></div><div>Maybe it is worth to consider `Thread.ofEphemeral()` tracked by weak reference<br>1. Implementation effort is minimal, there will be two maps of VT instead of one<br>2. Performance effort is zero, because only intentional, application VT can increase GC time (Volenti non fit iniuria)<br>3. Diagnostic still works<br><br>Regards <br>Michal Domagala</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">pon., 12 sty 2026 o 13:41 Alan Bateman <<a href="mailto:alan.bateman@oracle.com" target="_blank">alan.bateman@oracle.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 10/01/2026 15:55, Alex Miller wrote:<br>
> What is the likely future of the trackAllThreads flag?<br>
TBD. It's clearly an attractive nuisance right now and setting it to <br>
false is specific to the root "thread grouping". There is some <br>
performance work required in that area but otherwise I think it needs to <br>
be removed.<br>
<br>
-Alan<br>
</blockquote></div>