Loom in the Java Ecosystem Inside Java Newscast #34

With fibers, the two different uses would need to be clearly separated, as now a thread-local over possibly millions of threads is not a good approximation of processor-local data at all. This requirement for a more explicit treatment of thread-as-context vs. thread-as-an-approximation-of-processor is not limited to the actual ThreadLocal class, but to any class that maps Thread instances to data for the purpose of striping. If fibers are represented by Threads, then some changes would need to be made to such striped data structures. In any event, it is expected that the addition of fibers would necessitate adding an explicit API for accessing processor identity, whether precisely or approximately. It is the goal of this project to add a lightweight thread construct — fibers — to the Java platform.

Java Loom Project and Virtual Threads

Having been in the workings for several years, Loom got merged into the mainline of OpenJDK just recently and is available as a preview feature in the latest Java 19 early access builds. I.e. it’s the perfect time to get your hands onto virtual threads and explore the new feature. In this post I’m going to share an interesting aspect I learned about thread scheduling fairness for CPU-bound workloads running on Loom. Among other things, Java 19 ships with virtual threads, structured concurrency APIs, sealed types, and pattern matching in switch – all of them as previews, but still very cool! For production apps, adoption of virtual threads is best deferred until after they have been finalised and become GA in a future version of Java.

Java fibers in action

When these features are production ready, it will be a big deal for libraries and frameworks that use threads or parallelism. Library authors will see huge performance and scalability improvements while simplifying the codebase and making it more maintainable. Most Java projects using thread pools and platform threads will benefit from switching to virtual threads. Candidates include Java server software like Tomcat, Undertow, and Netty; and web frameworks like Spring and Micronaut. 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.

  • In any case, virtual threads will provide yet another tool for developers in the JVM ecosystem, and it will be very interesting to see how this functionality will grow and evolve in the years to come.
  • This model makes much more efficient use of the threads resource for IO-bound workloads, unfortunately at the price of a more involved programming model, which doesn’t feel familiar to many developers.
  • Operating systems typically allocate thread stacks as monolithic blocks of memory at thread creation time that cannot be resized later.
  • He is currently building an ecosystem of frameworks and libraries from scratch to power the tech behind Alumonium.
  • Virtual threads, on the other hand, allow us to gain the same throughput benefit without giving up key language and runtime features.
  • Virtual threads are an alternative implementation of java.lang.Thread which store their stack frames in Javas garbage-collected heap rather than in monolithic blocks of memory allocated by the operating system.
  • Why go to this trouble, instead of just adopting something like ReactiveX at the language level?

As Nicolai Parlog has explained, “Operating systems can’t increase the efficiency of platform threads, but the JDK will make better use of them by severing the one-to-one relationship between its threads and OS threads.” One of the most far-reaching Java 19 updates is the introduction of virtual threads. Virtual threads are part of Project Loom, and are available in Java 19 as a preview. For example, if we scale a million virtual threads in the application, there will be a million ThreadLocal instances along with the data they refer to. Such a large number of instances can put enough burden on the physical memory and it should be avoided. The Thread.setDaemon method cannot change a virtual thread to be a non-daemon thread.

It is expected that classes making use of contiuations will have a private instance of the continuation class, or even, more likely, of a subclass of it, and that the continuation instance will not be directly exposed to consumers of the construct. Code running inside a continuation is not expected to have a reference to the continuation, and the scopes normally have some fixed names . However, the yield point provides a mechanism to pass information from the code to the continuation instance and back.


We start with this type of test, from local to remote service, since it is good in some scenarios to collect end-user metrics and is a common scenario when starting with performance testing. This does not only reduce resource consumption allowing to generate more load from the same hardware but also keeps all the benefits of the existing Java Thread model . One of the points that differentiates JMeter from other tools is its concurrency model . @ktdotacademyWe have a community of more than 3000 followers and we only post programming-related content. Keep in mind that existing actor implementations continue working just fine using Java 19. However, creating a very basic actor implementation is also an option.

Java Loom Project and Virtual Threads

So in a thread-per-request model, the throughput will be limited by the number of OS threads available, which depends on the number of physical cores/threads available on the hardware. To work around this, you have to use shared thread pools or asynchronous concurrency, both of which have their drawbacks. Thread pools have many limitations, like thread leaking, deadlocks, resource thrashing, etc.

Fibers: Virtual threads in Java

This means that the performance of the virtual threading functionality is bound to improve in the future, including compared to Kotlin’s coroutines. In any case, virtual threads will provide yet another tool for developers in the JVM ecosystem, and it will be very interesting to see how this functionality will grow and evolve in the years to come. Much digital ink has already been spilled on this subject, and the consensus appears to be “probably not”. Virtual threads are a big change under the hood, but they are intentionally easy to apply to an existing codebase. Virtual threads will have the biggest and most immediate impact on servers like Tomcat and GlassFish. Such servers should be able to adopt virtual threading with minimal effort.

Java Loom Project and Virtual Threads

Keeping the OS threads free means that many virtual threads can run their Java code on the same OS thread, effectively sharing it. Traditionally, Java has treated the platform threads as thin wrappers around operating system threads. Creating such platform threads has always been costly , so Java has been using the thread pools to avoid the overhead in thread creation. The Loom project started in 2017 and has undergone many changes and proposals.

And the implementations provided by the core Java library provide the necessary code for you. This is why in the first preview of virtual threads in Java 19 includes a new class of ExecutorService that creates a new virtual Thread to run each submitted task, on-demand. See the Javadocs for factory method Executors.newVirtualThreadPerTaskExecutor() which also notes that the number of threads created by the Executor is unbounded. This new implementation of ExecutorService continues to provide application code with a convenient, out of the box way to run tasks asynchronously with a backwards compatible API, but now also takes advantage of virtual threads under the covers.

Community comments

In such a model, when an activity needs to perform IO, it initiates an asynchronous operation which will invoke a callback when complete. The framework will invoke that callback on some thread, but not necessarily the same thread that initiated the operation. This means developers must break their logic down into alternating IO and computational steps which are stitched together into a sequential workflow. Because a request only uses a thread when it is actually computing something, the number of concurrent requests is not bounded by the number of threads, and so the limit on the number of threads is less likely to be the limiting factor in application throughput.

But why would user-mode threads be in any way better than kernel threads, and why do they deserve the appealing designation of lightweight? It is, again, convenient to separately consider both components, the continuation and the scheduler. As the test results show, the test operation took much longer for traditional threads to execute compared to virtual threads. The goal of this Project is to explore and incubate Java VM features and APIs built on top of them for the implementation of lightweight user-mode threads , delimited continuations , and related features, such as explicit tail-call. Another important note is that virtual threads are always daemon threads, meaning they’ll keep the containing JVM process alive until they complete. Using conventional Java threads, when a server was idling on a request, an operating system thread was also idling, which severely limited the scalability of servers.

Everyone out of the pool

In the future, there may be more options to create custom schedulers. A more serious problem with async/await is the “function color” problem, where methods are divided into two kinds — one designed for threads and another designed for async methods — and the two do not interoperate perfectly. This is a cumbersome programming model, often with significant duplication, and would require the new construct to be introduced into every layer of libraries, frameworks, and tooling in order to get a seamless result. Why would we implement yet another unit of concurrency — one that is only syntax-deep — which does not align with the threads we already have?

Kubernetes service binding support for Reactive SQL Clients

While async/await makes code simpler and gives it the appearance of normal, sequential code, like asynchronous code it still requires significant changes to existing code, explicit support in libraries, and does not interoperate well with synchronous code. In other words, it does not solve what’s known https://globalcloudteam.com/ as the “colored function” problem. Currently, thread-local data is represented by the ThreadLocal class. Another is to reduce contention in concurrent data structures with striping. That use abuses ThreadLocal as an approximation of a processor-local (more precisely, a CPU-core-local) construct.

Launching the same number of blocking calls inside our LOOM Dispatcher, we’re expecting the total duration to be 1 million x 1000 ms / 1 million virtual threads, and we should finish in roughly 1 second, assuming JVM warmup and no overheads. Seeing these results, the big question of course is whether this unfair scheduling of CPU-bound threads in Loom poses a problem in practice or not. Ron and Tim had an expanded debate on that point, which I recommend you to check out to form an opinion yourself.

What user-facing form this construct may take will be discussed below. The goal is to allow most Java code to run inside fibers unmodified, or with minimal modifications. It is not a requirement of this project to allow native code called from Java code to run in fibers, although this may be possible in some circumstances. It is also not the goal of this project to ensure that every piece of code would enjoy performance benefits when run in fibers; in fact, some code that is less appropriate for lightweight threads may suffer in performance when run in fibers. Project Loom introduces lightweight and efficient virtual threads called fibers, massively increasing resource efficiency while preserving the same simple thread abstraction for developers.

The future

They were very much a product of their time, when systems were single-core and OSes didnt have thread support at all. Virtual threads have more in common with the user-mode threads found in other languages, such as goroutines in Go or processes in Erlang — but have the advantage of being semantically identical to the threads we already have. Virtual threads support the existing debugging and profiling interfaces, enabling easy troubleshooting, java enhancement proposals pursue virtual threads debugging, and profiling of virtual threads with existing tools and techniques. On the first line, we create a virtual thread factory that will handle the thread creation for the executor. Next, we call the new method for each executor and supply it the factory that we just created. Notice that calling newThreadPerTaskExecutor with a virtual thread factory is the same as calling newVirtualThreadPerTaskExecutor directly.

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. It will be fascinating to watch as Project Loom moves into the main branch and evolves in response to real-world use. As this plays out, and the advantages inherent in the new system are adopted into the infrastructure that developers rely on , we could see a sea change in the Java ecosystem. At a high level, a continuation is a representation in code of the execution flow. In other words, a continuation allows the developer to manipulate the execution flow by calling functions.


Nene Tereza 4500 Shëngjin, Albania


+355 677-144-407