Exploring Project Loom Revolutionizing Concurrency in Java by Arslan Mirza Javarevisited

As this plays out, and the advantages inherent in the new system are adopted into the infrastructure that developers rely on (think Java app servers like Jetty and Tomcat), we could see a sea change in the Java ecosystem. This kind of control is not difficult in a language like JavaScript where functions are easily referenced and can be called at will to direct execution flow. Beyond this very simple example is a wide range of considerations for scheduling. These mechanisms are not set in stone yet, and the Loom proposal gives a good overview of the ideas involved.

Why go to this trouble, instead of just adopting something like ReactiveX at the language level? The answer is both to make it easier for developers to understand, and to make it easier to move the universe of existing code. For example, data store drivers can be more easily transitioned to the new model. First, let’s see how many platform threads vs. virtual threads we can create on a machine.

Virtual threads

What happens now is that we jump directly back to line four, as if it was an exception of some kind. Then we move on, and in line five, we run the continuation once again. Not really, it will jump straight to line 17, which essentially means we are continuing from the place we left off.

At this point, the carrier thread is free to run another virtual thread. Technically, you can have millions of virtual threads that are sleeping without really paying that much in terms of the memory consumption. 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. As some of you who worked with ThreadLocal in more depth will know, a thread-local variable is not, in fact, local to one thread.

Understanding Java Loom Project and Virtual Threads

This is still work in progress, so everything can change. I’m just giving you a brief overview of how this project loom java project looks like. Essentially, the goal of the project is to allow creating millions of threads.

He co-leads JHipster and created the JDL Studio and KDash. He’s a Senior Developer Advocate for DevOps at Okta. He is also an international speaker and published author.

What is a class in Java?

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 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. Instead, the task is pulled from the tail of the deque. Eventually, a lightweight concurrency construct is direly needed that does not make use of these traditional threads that are dependent on the Operating system.

• Project Loomis is currently in development since it needs adjustments.
• Today with Java 19 getting closer to release, the project has delivered the two features discussed above.
• Then we move on, and in line five, we run the continuation once again.
• Just blindly switching from platform threads, the old ones, to virtual threads will change the semantics of your application.
• From the operating system’s perspective, every time you create a Java thread, you are creating a kernel thread, which is, in some sense you’re actually creating a new process.

Evaluate your application’s specific needs and experiment with fibers to determine where they can make the most significant impact. Project Loom’s compatibility with existing Java ecosystem components is a significant advantage. It allows you to gradually adopt fibers where they provide the most value in your application while preserving your investment in existing code and libraries. The primary goal of Project Loom is to make concurrency more accessible, efficient, and developer-friendly.

Thread Sleep

For example, let’s say you want to run something after eight hours, so you need a very simple scheduling mechanism. Doing it this way without Project Loom is actually just crazy. Creating a thread and then sleeping for eight hours, because for eight hours, you are consuming system resources, essentially for nothing. With Project Loom, this may be even a reasonable approach, because a virtual thread that sleeps consumes very little resources.

“Apps might see a big performance boost without having to change the way their code is written,” he said. “That’s very appreciated by our customers who are building software for not just a year or two, but for five to 10 years — not having to rewrite their apps all the time is important to them.” Virtual threads under Project Loom also require minimal changes to code, which will encourage its adoption in existing Java libraries, Hellberg said.

Why are some Java calls blocking?

But still, it provides Java apps with a good solution. It was supposed to be available in Java 17, we just got Java 18 and it’s still not there. I’m experimenting with Project Loom for quite some time already. If you’ve been coding in Java for a while, you’re probably well aware of the challenges and complexities that come with managing concurrency in Java applications. As a supplement to the discussion on cancellation, actors also run in a managed, coordinated environment.

Being an incubator feature, this might go through further changes during stabilization. It’s important to note that while Project Loom promises significant advantages, it’s not a one-size-fits-all solution. The choice between traditional threads and fibers should be based on the specific needs of your application. However, Project Loom provides a powerful tool that can simplify many aspects of concurrent programming in Java and deserves consideration in your development toolkit. One of the key advantages of fibers is their lightweight nature.

Filesystem calls

This piece of code is quite interesting, because what it does is it calls yield function. It voluntarily says that it no longer wishes to run because we asked that thread to sleep. Unparking or waking up means basically, that we would like ourselves to be woken up after a certain period of time. Before we put ourselves to sleep, we are scheduling an alarm clock. It will continue running our thread, it will continue running our continuation after a certain time passes by. In between calling the sleep function and actually being woken up, our virtual thread no longer consumes the CPU.