New candidate JEP: 425: Virtual Threads (Preview)

[Dr Heinz M. Kabutz]

ReentrantLock knows who currently owns it. Semaphore does not keep track at
all.

On Fri, 08 Apr 2022 at 18:21, Alex Otenko <oleksandr.otenko at gmail.com>
wrote:

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