New candidate JEP: 425: Virtual Threads (Preview)

[Dr Heinz M. Kabutz]

Excellent to see this in the formal JEP process.

A few comments on the text of the JEP:

In the section on "Using virtual threads vs. platform threads", we read:

"Things would be very different if this program used an ExecutorService 
that creates a new platform thread for each task, such as 
Executors.newCachedThreadPool(). The ExecutorService would attempt to 
create 10,000 platform threads, and thus 10,000 OS threads, and the 
program would crash on most operating systems."

Perhaps the language could perhaps be softened a bit to:

"Things would be very different if this program used an ExecutorService 
that might create a new platform thread for each task, such as 
Executors.newCachedThreadPool(). The ExecutorService could attempt to 
create 10,000 platform threads, and thus 10,000 OS threads, and the 
program might cause an OutOfMemoryError on some operating systems."

Neither of my two operating systems crashed with 10k threads (Mac OS X 
and Ubuntu Linux). Furthermore, on the Mac, starting the threads is slow 
enough so that some of the threads are reused for the one second sleep. 
Depending on the length of the sleep and the time it takes to launch a 
new thread, it is possible that with the cached thread pool slows things 
down sufficiently that we never see an OOME.

In the next paragraph we claim that if we change the tasks to 1m, we can 
achieve a throughput of 1m tasks per second (after sufficient warmup). I 
would be interested to see such a benchmark. In my experiments it takes 
about 2.2 seconds for those 1m tasks to get done, thus the throughput is 
quite a bit less than 1m/s.


In the paragraphs "Do not pool virtual threads", the recommendation is 
to use a Semaphore to limit the number of resources. The challenge with 
Semaphore is that it is a rather basic construct and it is impossible to 
figure out how many permits are outstanding, and likely to be returned, 
at any one time. We can release() Semaphores without ever calling 
acquire(), thus increasing the permits, or forget to call release() 
after acquire, thereby permanently decreasing them. I've seen this cause 
issues in production systems, where an uncaught exception decreased the 
semaphores permanently and thus decreased the throughput of the 
application. It is easy for this mistake to happen with Semaphores, and 
hard to find.

In the latest loom EA build (19-loom+5-429), the jcmd setting for 
dumping the threads seem to be:

$ jcmd <pid> JavaThread.dump -format=json <file>



Regards

Heinz
-- 
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java™ Specialists' Newsletter" - www.javaspecialists.eu
Java Champion - www.javachampions.org
JavaOne Rock Star Speaker
Tel: +30 69 75 595 262
Skype: kabutz

On 2022/04/06 19:10, mark.reinhold at oracle.com wrote:
> https://openjdk.java.net/jeps/425
>
>    Summary: Introduce virtual threads to the Java Platform. Virtual
>    threads are lightweight threads that dramatically reduce the effort
>    of writing, maintaining, and observing high-throughput concurrent
>    applications. This is a preview API.
>
> - Mark