<html class="apple-mail-supports-explicit-dark-mode"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">No. You aren’t listening. Your test case is broken. It will allocate 16gb of heap almost immediately. I’ve tried to explain this to you multiple ways. I think you are trolling. </div><div dir="ltr"><br><blockquote type="cite">On Jan 25, 2026, at 12:12 AM, Jianbin Chen <jianbin@apache.org> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">Hi Alan,<br><br>Thanks for the heads up — I’ll try running the performance tests again on the JDK 26 EA build.<br><br>That said, let’s continue the discussion around the main topic of this thread. I understand and largely agree with most people’s recommendations and the reasons why virtual threads shouldn’t be pooled. However, those recommendations generally assume that both our application and the third‑party libraries it depends on have been adapted to newer JDK features — for example, replacing ThreadLocal‑based buffer pools with proper object pools — and I fully appreciate the benefits of making those changes.<br><br>In reality it’s often much harder: many third‑party libraries must remain compatible with older JDK 8 users, so they are not eager to adopt newer platform features. That leaves users like us in a difficult position. For example, when JDK 21 shipped I eagerly adopted virtual threads, but then suffered from issues caused by third‑party libraries using synchronized, Object.wait, etc. I traced the pinned‑thread causes to such libraries — take apache commons‑pool as an example: you can see PRs addressing synchronized/Object.wait refactors here: <a href="https://github.com/apache/commons-pool/pulls">https://github.com/apache/commons-pool/pulls</a> — some of those PRs were opened two or three years ago and are still unapproved. Aren’t these kinds of problems part of the motivation behind JEP 491?<br><br>Given this reality, the only practical short‑term approach available to me appears to be a compromise: pool virtual threads but do not set a fixed maximum thread count. That way I can both limit buffer waste (which hurts performance) and still gain the throughput benefits of virtual threads.<br><br>Best regards, <br>Jianbin Chen</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Alan Bateman <<a href="mailto:alan.bateman@oracle.com">alan.bateman@oracle.com</a>> 于2026年1月25日周日 00:42写道：<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 24/01/2026 13:07, Jianbin Chen wrote:<br>
> Hi Alan,<br>
><br>
> I ran my example on JDK 21 because it uses Thread.sleep. In an earlier <br>
> message on the mailing list I learned that virtual‑thread performance <br>
> on JDK 25 was worse for this kind of scenario compared with JDK 21, <br>
> and that the issue is supposed to be fixed in JDK 25.0.3 — which has <br>
> not been released yet.<br>
<br>
I assume this is about JDK-8370887 [1], which may be an issue in some <br>
usages but I don't think has come up in this thread. For your <br>
Thread.sleep benchmark then maybe you can try it with the JDK 26 EA <br>
builds [2] where you know that issue has been fixed. As I said, I think <br>
that benchmark will need a bit of work (esp. on warmup) to get useful data.<br>
<br>
<br>
><br>
> That said, this does not affect the main point of my message: I’m <br>
> asking for advice about using pooled virtual threads to work around <br>
> third‑party libraries that implement buffer pools via ThreadLocal<br>
The advise is to not pool virtual threads. If a library is performing <br>
poorly because it assumes execution on a pooled thread then all we can <br>
suggest is to work with the maintainer of that library on the issue. <br>
Note that the JDK removed several usages of thread locals that were <br>
caching byte[] and other objects. That caching was beneficial a long <br>
time ago but not in recent recent/releases with significantly improved <br>
memory management and GC.<br>
<br>
-Alan<br>
<br>
[1] <a href="https://bugs.openjdk.org/browse/JDK-8370887" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8370887</a><br>
[2] <a href="https://jdk.java.net/26/" rel="noreferrer" target="_blank">https://jdk.java.net/26/</a><br>
</blockquote></div>
</div></blockquote></body></html>