How to observe "temporarily expanding the parallelism of the scheduler"?

[Alan Bateman]

On 13/05/2025 17:40, Cay Horstmann 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.

I assume this is regular file I/O so you won't be able to observe this 
behavior. If you use the synchronized I/O file integrity options (SYNC 
or DSYNC) then writes will be written synchronously and you should be 
able to see that parallelism is temporary increased during these 
options. So FileChannel with StandardOpenOption.SYNC/DSYNC or 
RandomAccessFile with "rws" or "rwd" mode.

You can use `jcmd <pid> Thread.vthread_scheduler` as another way to 
monitor the scheduler. It has additional counters beyond what is exposed 
in VirtualThreadSchedulerMXBean.

-Alan