Thread by @denis_makogon

It's time for #JavaTuesdayThread!

You know that JDK 19 will be released in 2 months on Sept. 20th. It will bring some major changes to the JDK. Project #Loom is one of those HUGE changes I want to talk about a little bit more. #Java #OpenJDK

JEP 425 introduces Virtual Threads. The most interesting thing is that the JDK was reworked to make it possible to block both platform and virtual threads in different ways.

While thread blocking methods will put on pause the whole platform thread, the virtual thread blocking wouldn't block its underlying carrier thread so it can pick up the segment of another virtual thread to execute.

There are a lot of blocking methods in JDK. A simple PrintStream::println will make a scheduler park a virtual thread until it is done. So, eventually, a virtual thread will be executed on multiple carrier threads, here's how to check it:

The result would be pretty verbose:

Not only I/O operation make a scheduler park a virtual thread. Ordinary Thread::sleep was also reworked to make a distinction between a platform thread and a virtual one. So, every method inside the JDK that was causing a thread to block will know how to treat a virtual thread.

Worth to say that, when a virtual thread is parked, the whole execution stack of it is moved to a heap if it has more things to do after blocking method completion. So, it'll be moved back once a virtual thread can proceed (unparked and assigned to a carrier thread).

The most interesting park of virtual threads is the Continuation. The concept is very similar to Python's generators (and coroutines before v3.6).

A virtual thread holds an instance of the continuation that has a yield point and can be started or continued (through Continuation::run method) by the external subsystem.

So, it appears to be that the execution of a virtual thread is the execution of the continuation object. A virtual thread blocking makes the continuation yield.

Note: Please be aware that as of now, Continuations API isn't a public one. However, it may change in the future.

You see, virtual threads will be a very hot topic and we'll hear more talks and will see more experiments soon enough.

BONUS! The last time I've written about Loom I made an experiment by launching 2M virtual threads running HTTP requests, it took me quite some time to finish. But this time I decided to reduce the scope and see where's the limit and how the program will fail.

It took around 12s to launch 10M virtual threads, and 30s to launch 15M. But then I just ran out of RAM, so the experiment failed at around 16M virtual threads. The numbers are literally crazy compared to the 4073 platform threads that the JVM can occupy before it crashed.

If you want to learn more about virtual threads, watch @JosePaumard's #JEPCafe or attend one of his workshops, it's definitely worth it!