<div dir="auto"><div>Hello Peter,</div><div dir="auto">I find multiple misunderstandings in your response. Let me clarify these.</div><div dir="auto"><br></div><div dir="auto"><div dir="auto">About the process: Jianbin is using a specific product maintained by a vendor for an older JDK release. The vendor should ask the Jianbin to try on the latest JDK release before asking to forwarding this to loom. We cannot expect general users to understand the order of steps to take here.</div><div dir="auto"><br></div><div dir="auto">About backporting: JEP 14, the tip and tail release model, explicitly rules out the tail releases from addition of performance improvements; JEP 491 is clearly not crucial to the security of older releases and should not be backported.</div><div dir="auto"><br></div><div dir="auto">About LTS releases: they are not associated with the active development of JDK, as evident on <a href="http://jdk.java.net" target="_blank" rel="noreferrer">jdk.java.net</a>. Any vendor can declare any release supported; they must at least provide quarterly updates with all security fixes. For openjdk, all past releases that are supported in open source are discussed on the jdk-updates-dev list. Oracle offers premium support (not part of openjdk) for their chosen releases called LTS releases, and openjdk's jdk updates project decides to support the same releases. The argument that active jdk development is responsible for maintenance of a particular supported release, including ones considered LTS, does not stand.</div><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Tue, Jul 1, 2025, 23:15 Peter Eastham <<a href="mailto:petereastham@gmail.com" target="_blank" rel="noreferrer">petereastham@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="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" 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" 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" 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></div></div>