New candidate JEP: 425: Virtual Threads (Preview)

[Eric Kolotyluk]

If we should not use thread pools, and Semaphores and other mechanisms 
such as ReentrantLock also have problems, would this be a reason for 
Loom to add some specific API support for this kind of limiting?

Thanks for pointing out the issues with Semaphores... are the any 
problems with using ReentrantLock?

Cheers, Eric

On 2022-04-08 8:48 a.m., Dr Heinz M. Kabutz wrote:
> 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