New candidate JEP: 425: Virtual Threads (Preview)

[Alex Otenko]

I mean the cases that you mentioned - like, forget to unlock.

Alex

On Fri, 8 Apr 2022, 16:48 Dr Heinz M. Kabutz, <heinz at javaspecialists.eu>
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
>