Project Loom: Revolution in Java Concurrency or Obscure Implementation Detail?

You just create treads as if it was a very native, very low footprint abstraction, which is not the case right now. The first takeaway is that this may revolutionize the way you work with concurrent code. On the other hand, we can already see that even though the feature wasn’t yet released, you have to be aware of the shortcomings. And also, there are a few other disadvantages or limitations of Project Loom that you must be aware of. Otherwise, you will just shoot yourself in the foot.

However, it turns out, first of all, it’s very easy with that tool to show you the actual Java threads. Rather than showing a single Java process, you see all Java threads in the output. More importantly, you can actually see, what is the amount of CPU consumed by each and every of these threads? Does it mean that Linux has some special support for Java?

As you might have noticed from the examples, Kotlin’s syntax offers more flexibility in terms of nesting. To reach the same level of convenience in Java you probably have to move the nested code into separate functions to actually keep it readable. But once you did that, you loose the context of “Loom”. This means that you cannot see any more if a function is suited for virtual threads or not. Loom has a list with virtual thread-friendly functions, indicating that you have to know in advance if a function can be used or not. In contrast, Kotlin has the suspend keyword, which marks a function for consumption in a coroutine context.

Using Java’s Project Loom to build more reliable distributed systems

This means that JFR and JVMTI would need to accommodate fibers, and relevant platform MBeans may be added. We will call that https://globalcloudteam.com/ feature unwind-and-invoke, or UAI. It is not the goal of this project to add an automatic tail-call optimization to the JVM.

• This uses the newThreadPerTaskExecutor with the default thread factory and thus uses a thread group.
• If they are serializable, we might as well make them cloneable, as the ability to clone continuations actually adds expressivity .
• If instead it is backed by a single operating system thread, it will deadlock.
• Virtual threads give the developer the opportunity to develop using traditional blocking I/O, since one of the big perks of virtual threads is that blocking a virtual thread does not block the entire OS thread.
• The exception stacktraces are not useful because the composed futures would all be computed on different threads.

That is what project Loom sets out to do, by introducing a new virtual thread class called a fiber. Loom is a newer project in the Java/JVM ecosystem that attempts to address limitations in the traditional concurrency model. In particular, Loom offers a lighter alternative to threads along with new language constructs for managing them. Project Loom is another major feature in Java 19 that lets developers build applications in a scalable way, without having to choose between building performant code or code that is easy to monitor and debug, said Arimura. Chad Arimura, vice-president of Java developer relations at Oracle, said Project Amber, for example, is a language level feature that was built to support emerging software development trends.

Releases

It’s worth mentioning that virtual threads are a form of “cooperative multitasking”. Native threads are kicked off the CPU by the operating system, regardless of what they’re doing . Even an infinite loop will not block the CPU core this way, others will still get their turn. On the virtual thread level, however, there’s no such scheduler – the virtual thread itself must return control to the native thread. Virtual threads may be new to Java, but they aren’t new to the JVM. Those who know Clojure or Kotlin probably feel reminded of «coroutines» (and if you’ve heard of Flix, you might think of «processes»).

However, the yield point provides a mechanism to pass information from the code to the continuation instance and back. When a continuation suspends, no try/finally blocks enclosing the yield point are triggered (i.e., code running in a continuation cannot detect that it is in the process of suspending). Fibers are, then, what we call Java’s planned user-mode threads. This section will list the requirements of fibers and explore some design questions and options. It is not meant to be exhaustive, but merely present an outline of the design space and provide a sense of the challenges involved. The word thread will refer to the abstraction only and never to a particular implementation, so thread may refer either to any implementation of the abstraction, whether done by the OS or by the runtime.

Building Loom

Virtual threads, also referred to as green threads or user threads, moves the responsibility of scheduling from the OS to the application, in this case the JVM. This allows the JVM to take advantage of its knowledge about what’s happening in the virtual threads when making decision on which threads to schedule next. As one of the reasons for implementing continuations as an independent construct of fibers is a clear separation of concerns. Continuations, therefore, are not thread-safe and none of their operations creates cross-thread happens-before relations. Establishing the memory visibility guarantees necessary for migrating continuations from one kernel thread to another is the responsibility of the fiber implementation.

Java used to have green threads, at least in Solaris, but modern versions of Java use native threads. Native threads are nice, but relatively heavy, and you might need to tune the OS if you want to have tens of thousands of them. Exhibits exact the same behavior as platform threads. I skimmed the blog post and it seems to say that if you write code to use all the memory that would be statically allocated by normal threads, then dynamically allocated threads use the same amount which.. There’s no magic in threads that will make your code smaller, the argument is that if you don’t need that much space then dynamically allocated threads will use less memory.

Carrier Thread

For example, capping the number of connections to a relational database is best implemented using a connection pool as it provides additional features such as a connection factory, connection validation, dynamic resizing, eviction etc. Thread pools are primarily used to avoid the CPU overhead of thread creation. However with virtual threads this overhead is insignificant. One example of this, is the thread pool which a web server creates for the threads used to service incoming HTTP requests. Not only may your favourite pure Java web server no longer have a thread pool, but you’ll no longer have to size and tune it. We also believe that ReactiveX-style APIs remain a powerful way to compose concurrent logic and a natural way for dealing with streams.

Java threads provided a relatively simple abstraction for writing concurrent applications. A mismatch in several orders of magnitude has a big impact. In addition, blocking (waiting on I/O) for a virtual thread is also cheap – there is no longer a cost in terms of lower CPU utilisation as there is with platform threads. Therefore you no longer need to write code that avoids blocking a thread (e.g. by using reactive, async APIs) – it’s a waste of time. Now we have virtual threads, writing imperative code that blocks on I/O is ok. This is a benefit because imperative, blocking code is a lot easier to maintain than async code.

Featured in DevOps

Many developers perceive the different style as “cognitive ballast”. Instead of dealing with callbacks, observables, or flows, they would rather stick to a sequential list of instructions. Represent fibers as a Fiber class, and factor out the common API for Fiber and Thread into a common super-type, provisionally called Strand. Thread-implementation-agnostic code would be programmed against Strand, so that Strand.currentStrand would return a fiber if the code is running in a fiber, and Strand.sleep would suspend the fiber if the code is running in a fiber. JDK libraries making use of native code that blocks threads would need to be adapted to be able to run in fibers. In particular this implies changing the java.io classes.

Wrapping up a function in a continuation doesn’t really run that function, it just wraps a Lambda expression, nothing specific to see here. However, if I now run the continuation, so if I call run on that object, I will go into foo function, and it will continue running. It runs the first line, and then goes to bar method, it goes to bar function, it continues running.

There is an interrupt triggered when response is made available from the external call and the callback is invoked on another thread from the thread pool. Virtual threads are a new lightweight implementation of a Thread coming to Java. They’re available now as a preview in Java 19, allowing you to trial their usage in conjunction with existing apps. They promise increased throughput for apps whose performance is limited by blocking I/O, by making more effective use of O/S , maximising the available hardware resources.

Where Virtual Threads make sense

For example, on a single core machine, in the absence of a sleep or control primitive like a CountDownLatch, it’s unlikely that the above bug could be found. By generating a lot of simulated context switching, a broader set of possible interleavings can be cheaply explored. This makes it more likely that the author will find bugs that they were not specifically looking for. If the ExecutorService involved is backed by multiple operating system threads, then the task will not be executed in a deterministic fashion because the operating system task scheduler is not pluggable. If instead it is backed by a single operating system thread, it will deadlock. When the FoundationDB team set out to build a distributed database, they didn’t start by building a distributed database.

Continuations

Like any ambitious new project, Loom is not without its challenges. Dealing with sophisticated interleaving of threads is always going to be a complex challenge, and we’ll have to wait to see exactly what library support and design patterns emerge to deal with these situations. 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. This model is project loom java fairly easy to understand in simple cases, and Java offers a wealth of support for dealing with it. As noted by Sharat Chander, Oracle’s director of Java SE product management, JDK 17 was the second LTS under the release cadence announced in 2018. With it, Oracle introduced «new and simpler license terms» that allowed companies to use it at «no cost for at least the next three years, allowing one full year of overlap with the next LTS release.»

Building responsiveness applications is a never-ending task. With the rise of powerful and multicore CPUs, more raw power is available for applications to consume. In Java, threads are used to make the application work on multiple tasks concurrently. A developer starts a Java thread in the program, and tasks are assigned to this thread to get processed. Threads can do a variety of tasks, such as read from a file, write to a database, take input from a user, and so on. It is the goal of this project to add a lightweight thread construct — fibers — to the Java platform.

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. This is an advertising talk, because you probably won’t create as many. Technically, it is possible, and I can run millions of threads on this particular laptop.

Project Loom is fundamentally about Blocking and Policies and Procedures for handling blocking. Sometimes, a customer would block the process, such as the teller needed to make a phone call to get some information. You can reach us directly at or you can also ask us on the forum. Deepu is a polyglot developer, Java Champion, and OSS aficionado. He co-leads JHipster and created the JDL Studio and KDash.

As there are two separate concerns, we can pick different implementations for each. Currently, the thread construct offered by the Java platform is the Thread class, which is implemented by a kernel thread; it relies on the OS for the implementation of both the continuation and the scheduler. Again, threads — at least in this context — are a fundamental abstraction, and do not imply any programming paradigm. In particular, they refer only to the abstraction allowing programmers to write sequences of code that can run and pause, and not to any mechanism of sharing information among threads, such as shared memory or passing messages.

My machine is Intel Core i H with 8 cores, 16 threads, and 64GB RAM running Fedora 36. Java has had good multi-threading and concurrency capabilities from early on in its evolution and can effectively utilize multi-threaded and multi-core CPUs. Java Development Kit 1.1 had basic support for platform threads (or Operating System threads), and JDK 1.5 had more utilities and updates to improve concurrency and multi-threading. JDK 8 brought asynchronous programming support and more concurrency improvements.