How to observe "temporarily expanding the parallelism of the scheduler"?
Heinz Kabutz
heinz at javaspecialists.eu
Tue May 13 16:55:44 UTC 2025
https://openjdk.org/jeps/491
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun/Oracle Java Champion
JavaOne Rockstar Speaker
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz
On Tue, 13 May 2025 at 19:41, Cay Horstmann <cay.horstmann at gmail.com> wrote:
> https://openjdk.org/jeps/444 states:
>
> "However, some blocking operations in the JDK do not unmount the virtual
> thread, and thus block both its carrier and the underlying OS thread. This
> is because of limitations at either the OS level (e.g., many filesystem
> operations) or the JDK level (e.g., Object.wait()). The implementations of
> these blocking operations compensate for the capture of the OS thread by
> temporarily expanding the parallelism of the scheduler. Consequently, the
> number of platform threads in the scheduler's ForkJoinPool may temporarily
> exceed the number of available processors."
>
> I tried to create such a situation, but was so far unsuccessful, with 10K
> virtual threads doing frequent file operations, in quite a few different
> ways. I always saw exactly 14 carrier threads in jconsole, which is the
> #cores on my machine. This was with Java 24 on Linux.
>
> I'd be grateful for a tip on how to demo this behavior.
>
> Cheers,
>
> Cay
>
> --
>
> Cay S. Horstmann | https://horstmann.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20250513/b7e89c49/attachment.htm>
More information about the loom-dev
mailing list