Virtual threads created more platform threads

[Chen Liang]

Hello Peter,
I find multiple misunderstandings in your response. Let me clarify these.

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.

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.

About LTS releases: they are not associated with the active development of
JDK, as evident on jdk.java.net. 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.

On Tue, Jul 1, 2025, 23:15 Peter Eastham <petereastham at gmail.com> wrote:

> 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.
>
> 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)
>
>
> Thanks,
> - Peter
>
> 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.
>
>
>
> On Tue, Jul 1, 2025, 9:17 PM Chen Liang <liangchenblue at gmail.com> wrote:
>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> On Tue, Jul 1, 2025 at 9:47 PM Jianbin Chen <jianbin at apache.org> wrote:
>>
>>>
>>> Hi Loom-dev Community,
>>>
>>> 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:
>>> https://github.com/adoptium/adoptium-support/issues/1319. I hope to
>>> receive some help from the community regarding this matter. Thank you.
>>> Additionally, I'd like to know if this situation will still occur in JDK
>>> 24 and above?
>>>
>>> Best Regards.
>>> Jianbin Chen, github-id: funky-eyes
>>>
>>>
>>> Best Regards.
>>> Jianbin Chen, github-id: funky-eyes
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20250701/594ae236/attachment.htm>