<div dir="auto">Hi Liang,<div dir="auto"><br><div dir="auto">Thank you and everyone for your patient answers. I verified this with JDK 24, and the same example did not show platform thread growth. However, there's one thing I don't understand: why are these threads never reclaimed? Most of them are in a waiting state - isn't this a waste of resources? Sometimes it increases by hundreds of threads. Is there any way to suppress this behavior on JDK 21?<br><br><div data-smartmail="gmail_signature" dir="auto">Best Regards.<br>Jianbin Chen, github-id: funky-eyes </div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Chen Liang <<a href="mailto:liangchenblue@gmail.com">liangchenblue@gmail.com</a>> 于 2025年7月2日周三 12:58写道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Hello Jianbin, please provide a test case that can reproduce this issue on 24. 21 is not supported by active JDK development.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 1, 2025, 23:52 Jianbin Chen <<a href="mailto:jianbin@apache.org" target="_blank" rel="noreferrer">jianbin@apache.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Hi everyone, <div dir="auto">thank you for your replies and assistance. So this issue occurring in JDK 21 is considered normal behavior, correct? However, I've observed that these expanded threads are not being garbage collected - they remain in a waiting state for several minutes without disappearing. Sometimes they can expand to several hundred threads, and these threads, once created, remain unused, continuously wasting thread resources. Therefore, I'm attaching a local reproduction example of this issue to ensure the information in this email is complete.<br><div dir="auto">-Djava.util.concurrent.ForkJoinPool.common.parallelism=1</div><div dir="auto">`</div><div dir="auto">The following example clearly shows the forkjoinpool expanding. I have also recorded the runtime stack trace for this and submitted it as an attachment.</div><div dir="auto"><br></div><div dir="auto">```</div><div dir="auto"> public static void main(String[] args) throws InterruptedException {</div><div dir="auto"> Executor executor = ThreadPoolFactory.newVirtualThreadPerTaskExecutor();</div><div dir="auto"> String a = "a";</div><div dir="auto"> executor.execute(() -> {</div><div dir="auto"> synchronized (a) {</div><div dir="auto"> try {</div><div dir="auto"> a.wait();</div><div dir="auto"> } catch (InterruptedException e) {</div><div dir="auto"> throw new RuntimeException(e);</div><div dir="auto"> }</div><div dir="auto"> }</div><div dir="auto"> });</div><div dir="auto"> executor.execute(() -> {</div><div dir="auto"> synchronized (a) {</div><div dir="auto"> try {</div><div dir="auto"> a.wait();</div><div dir="auto"> } catch (InterruptedException e) {</div><div dir="auto"> throw new RuntimeException(e);</div><div dir="auto"> }</div><div dir="auto"> }</div><div dir="auto"> });</div><div dir="auto"> Thread.sleep(120000);</div><div dir="auto"> }</div><div dir="auto">```</div><div dir="auto">After switching to using condition, it can be clearly observed through jstack that the forkjoinpool did not expand as many threads, but 3 threads still appeared, which might be related to incorrect usage of my JVM parameters.</div><div dir="auto"><br></div><div dir="auto">```</div><div dir="auto"> public static void main(String[] args) throws InterruptedException {</div><div dir="auto"> Executor executor = ThreadPoolFactory.newVirtualThreadPerTaskExecutor();</div><div dir="auto"> List<ReentrantLock> list = new ArrayList<>();</div><div dir="auto"> list.add(new ReentrantLock());</div><div dir="auto"> list.add(new ReentrantLock());</div><div dir="auto"> list.add(new ReentrantLock());</div><div dir="auto"> list.add(new ReentrantLock());</div><div dir="auto"> list.add(new ReentrantLock());</div><div dir="auto"> list.add(new ReentrantLock());</div><div dir="auto"> for (int i = 0; i < list.size(); i++) {</div><div dir="auto"> ReentrantLock value = list.get(i);</div><div dir="auto"> Condition condition = value.newCondition();</div><div dir="auto"> executor.execute(() -> {</div><div dir="auto"> value.lock();</div><div dir="auto"> try {</div><div dir="auto"> condition.await();</div><div dir="auto"> } catch (InterruptedException e) {</div><div dir="auto"> throw new RuntimeException(e);</div><div dir="auto"> }finally {</div><div dir="auto"> value.unlock();</div><div dir="auto"> }</div><div dir="auto"> });</div><div dir="auto"> }</div><div dir="auto"> Thread.sleep(120000);</div><div dir="auto"> }</div><div dir="auto">```<br><br><div data-smartmail="gmail_signature" dir="auto">Best Regards.<br>Jianbin Chen, github-id: funky-eyes </div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Peter Eastham <<a href="mailto:petereastham@gmail.com" rel="noreferrer noreferrer" target="_blank">petereastham@gmail.com</a>> 于 2025年7月2日周三 12:16写道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>I hope to not create noise with my own comments, and I will concur with you that JEP 491 should mean this is resolved in Java 24, which Jianbin Chen should try out before and then alongside Robert's recommendation for creating a very simple reproduction.</div><div dir="auto"><br></div><div dir="auto">As Java 21 is still the current LTS, it isn't completely unreasonable to forward concerns to the mailing list. My understanding in this particular case is that JEP 491 is not going to be back ported to Java 21 as it has a dependency from a change in Java 23. (Potentially more, I can't remember the conversation completely, I only skimmed that email chain)</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">- Peter</div><div dir="auto"><br></div><div dir="auto">P.S. As I do a similar job, I'd like to call out that Vendors letting the occasional support question slip into here is a fine price to pay for the amount of questions they handle instead.</div><div dir="auto"><br></div><div dir="auto"><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Tue, Jul 1, 2025, 9:17 PM Chen Liang <<a href="mailto:liangchenblue@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">liangchenblue@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello, I don't think this would happen for JDK 24 - JEP 491 removed the code that calls Blocker in Object.wait, which is exactly the goal of that JEP.<div><div><br></div><div>Note that virtual threads are still pinned when call stack goes into native, as native execution may pass address to stack variables that will be lost in context switches. In these cases, the traditional managed block happens again.</div></div><div><br>P.S. I personally think it is somewhat not responsible for JDK vendors to ask users to upstream a question for an older JDK release that might no longer apply on the latest release to a development-oriented mailing list.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 1, 2025 at 9:47 PM Jianbin Chen <<a href="mailto:jianbin@apache.org" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">jianbin@apache.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"><br></div>Hi Loom-dev Community,<div dir="auto"><br></div><div dir="auto">I have a question about platform thread creation triggered by calling future.get() within virtual threads, and I would like to ask the community for assistance. The detailed information can be found in this issue: <a href="https://github.com/adoptium/adoptium-support/issues/1319" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://github.com/adoptium/adoptium-support/issues/1319</a>. I hope to receive some help from the community regarding this matter. Thank you.</div><div dir="auto">Additionally, I'd like to know if this situation will still occur in JDK 24 and above?</div><div dir="auto"><br></div><div dir="auto">Best Regards.</div><div dir="auto">Jianbin Chen, github-id: funky-eyes</div><div dir="auto"><br><br><div dir="auto">Best Regards.<br>Jianbin Chen, github-id: funky-eyes </div></div></div>
</blockquote></div>
</blockquote></div></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>