Java 20 Doubling down on the Loom Project by Oskar

With Project Loom, this may be even a reasonable approach, because a virtual thread that sleeps consumes very little resources. You don’t pay this huge price of scheduling operating system resources and consuming operating system’s memory. There’s also a different algorithm or a different initiative coming as part of Project Loom called structured concurrency. Essentially, it allows us to create an ExecutorService that waits for all tasks that were submitted to it in a try with resources block.

Project Loom allows the use of pluggable schedulers with fiber class. In asynchronous mode, ForkJoinPool is used as the default scheduler. It works on the work-stealing algorithm loom java so that every thread maintains a Double Ended Queue (deque) of tasks. It executes the task from its head, and any idle thread does not block while waiting for the task.

Java 19 Features: Virtual Threads, Record Patterns & Structured Concurrency

Most JVM implementations today implement Java threads as thin direct wrappers around operating system threads, called sometimes heavyweight, OS-managed threads platform threads. With Project Loom, we will have at least one more such option to choose from. In the preview build of Java, call the new Executors.newVirtualThreadPerTaskExecutor() to get an executor service backed by virtual threads. As to the question about when not to use virtual threads, there are some obvious cases. E.g. when your threads heavily interact with native code, which knows nothing about virtual threads, or when you depend on some detail that has changed for virtual threads, like the ability to subclass Thread. For example, CPU-bound operations do not benefit from having more threads than CPU cores, so they do not benefit from the multitude of virtual threads, but that doesn’t mean that they would be harmed.

• As far as JVM is concerned, they do not exist, because they are suspended.
• In subcribeOn() we provide a Scheduler that creates a dedicated thread for executing that blocking operation.
• You can also block in Reactive code, it’s just normally not a good idea.
• But if there are any blocking (or) high CPU operations, we let this activity happen on a separate thread asynchronously.
• Better handling of requests and responses is a bottom-line win for a whole universe of existing and to-be-built Java applications.

Before looking more closely at Loom’s solution, it should be mentioned that a variety of approaches have been proposed for concurrency handling. In general, these amount to asynchronous programming models. Some, like CompletableFutures and Non-Blocking IO, work around the edges of things by improving the efficiency of thread usage. Others, like JavaRX (the Java implementation of the ReactiveX spec), are wholesale asynchronous alternatives. The solution is to introduce some kind of virtual threading, where the Java thread is abstracted from the underlying OS thread, and the JVM can more effectively manage the relationship between the two. That is what project Loom sets out to do, by introducing a new virtual thread class called a fiber.

Things to Do with Looms

I expect most Java web technologies to migrate to virtual threads from thread pools. Java web technologies and trendy reactive programming libraries like RxJava and Akka could also use structured concurrency effectively. This doesn’t mean that virtual threads will be the one solution for all; https://www.globalcloudteam.com/ there will still be use cases and benefits for asynchronous and reactive programming. This is still work in progress, so everything can change. I’m just giving you a brief overview of how this project looks like. Essentially, the goal of the project is to allow creating millions of threads.

It’s much easier when you have multiple CPUs, but most of the time, this is almost always the case, you will never have as many CPUs as many kernel threads are running. This mechanism happens in the operating system level. Before we actually explain, what is Project Loom, we must understand what is a thread in Java? I know it sounds really basic, but it turns out there’s much more into it. First of all, a thread in Java is called a user thread.

Alternatives to fibers in Java

Suddenly, you have to rely on these low level CountDownLatches, semaphores, and so on. I barely remember how they work, and I will either have to relearn them or use some higher level mechanisms. This is probably where reactive programming or some higher level abstractions still come into play.

The second of these stages is commonly the last development phase before incorporation as a standard under OpenJDK. In the simplest terms a virtual thread is not directly tied to a particular OS thread while a platform thread is a thin wrapper around an OS thread. The last pitfall is a bit subtle but important for scalability since Virtual Threads can scale in number orders of magnitude more compared to platform threads, and it’s about thread inheritance.

Virtual threads

While things have continued to improve over multiple versions, there has been nothing groundbreaking in Java for the last three decades, apart from support for concurrency and multi-threading using OS threads. Reactive frameworks typically provide a way to run non-reactive code using another thread or similar. You can configure this to use virtual threads and then start rewriting the code bottom-up. You can try to migrate it top-down – you make sure that the calling code is executed in virtual threads and rewrite that step by step to block.

You can also create a ThreadFactory if you need it in some API, but this ThreadFactory just creates virtual threads. Another thing that’s not yet handled is preemption, when you have a very CPU intensive task. Let’s say you have 4 CPU cores, and you create 4 platform threads, or 4 kernel threads that are doing very CPU intensive work, like crunching numbers, cryptography, hashing, compression, encoding, whatever. If you have 4 physical threads, or platform threads doing that, you’re essentially just maxing your CPU.

Structured Concurrency

Supposing the filter object will be loaded and available globally to the program, (to avoid extra loading time), the process function will be like the one below. Already, Java and its primary server-side competitor Node.js are neck and neck in performance. An order of magnitude boost to Java performance in typical web app use cases could alter the landscape for years to come.

Then, you would block for called reactive code while the code calling your code treats your rewritten code as non-reactive code. For example, if you want to serialize one task after another, we would use an executor service backed by a single thread. In Minecraft, the loom is another important item in your inventory. A loom is a new type of crafting table that allows you to take a banner, a dye and a banner pattern and weave them together to create amazing new banners. The loom makes it easy to create fancy banners with lots of different patterns to choose from. Virtual threads under Project Loom also require minimal changes to code, which will encourage its adoption in existing Java libraries, Hellberg said.

Learn about Project Loom and the lightweight concurrency for JavaJVM.

From that perspective, I don’t believe Project Loom will revolutionize the way we develop software, or at least I hope it won’t. It will significantly change the way libraries or frameworks can be written so that we can take advantage of them. The reason I’m so excited about Project Loom is that finally, we do not have to think about threads. When you’re building a server, when you’re building a web application, when you’re building an IoT device, whatever, you no longer have to think about pooling threads, about queues in front of a thread pool. At this point, all you have to do is just creating threads every single time you want to. It works as long as these threads are not doing too much work.