New candidate JEP: 425: Virtual Threads (Preview)

[Alex Otenko]

I think that problem is not unique to semaphores. Using j.u.c.Lock has the
same problem.

Alex

On Fri, 8 Apr 2022, 15:57 Dr Heinz M. Kabutz, <heinz at javaspecialists.eu>
wrote:

> 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
>