java Project loom: Why are virtual threads not the default?

Discussions over the runtime characteristics of virtual threads should be brought to the loom-dev mailing list. Moreover, explicit cooperative scheduling points provide little benefit on the Java platform. The duration of a blocking operation can range from several orders of magnitude longer than those nondeterministic pauses to several orders of magnitude shorter, and so explicitly marking them is of little help. A better way to control latency, and at a more appropriate granularity, is deadlines. An alternative solution to that of fibers to concurrency’s simplicity vs. performance issue is known as async/await, and has been adopted by C# and Node.js, and will likely be adopted by standard JavaScript. As there are two separate concerns, we can pick different implementations for each.

So, stackful coroutines are more powerful and general-purpose than stackless coroutines. This programming style is typical of functional programming and is known as Continuation Passing Style (CPS). Here, the control is passed explicitly in the form of a continuation. This is somewhat similar to the asynchronous programming style where we pass a callback function to get notified. However, with coroutines in Kotlin, the compiler implicitly handles the continuations.

What does this mean to regular Java developers?

This is quite similar to coroutines, like goroutines, made famous by the Go programming language (Golang). Of course, the idea behind Project Loom is not just to provide a construct like the virtual thread in Java but also to address some of the other issues that arise due to them. For instance, a flexible mechanism to pass data among a large number of virtual threads. A more intuitive way to organize and supervise so many virtual threads, a concept close to structured concurrency.

It’s due to the parked virtual threads being garbage collected, and the JVM is able to create more virtual threads and assign them to the underlying platform thread. A possible solution to such problems is the use of asynchronous concurrent APIs. Provided that such APIs don’t block the kernel thread, it gives an application a finer-grained concurrency construct on top of Java threads. Project Looms changes the existing Thread implementation from the mapping of an OS thread, to an abstraction that can either represent such a thread or a virtual thread.

What does this mean to Java library developers?

One of the main goals of Project Loom is to actually rewrite all the standard APIs. For example, socket API, or file API, or lock APIs, so lock support, semaphores, CountDownLatches. All of these APIs need to be rewritten so that they play well with Project Loom. However, there’s a whole bunch of APIs, most importantly, the file API. There’s a list of APIs that do not play well with Project Loom, so it’s easy to shoot yourself in the foot.

• Technically, you can have millions of virtual threads that are sleeping without really paying that much in terms of the memory consumption.
• Imagine being alerted to any regression or code smell as you’re
  running and debugging locally.
• Finally, I’ll extrapolate on what effects the latter could have on the ecosystem.
• For this program, a pool with 200 platform threads can only achieve a throughput of 200 tasks-per-second, whereas virtual threads achieve a throughput of about 10,000 tasks-per-second (after sufficient warmup).
• With just a few changes, you can start using virtual threads in your Spring application and take advantage of its performance improvements.

It was difficult to scale green threads over multiple processors and hence benefit from parallelism on multi-core systems. To get around this problem and simplify the concurrent programming model, Java decided to abandon green threads in version 1.3. Two more good news with virtual threads First, thread local variables also work in the same way.

Fibers: The Building Blocks of Lightweight Threads

The job is broken down into multiple smaller tasks, executed simultaneously to complete it more quickly. To summarize, parallelism is about cooperating on a single task, whereas concurrency is when different tasks compete for the same resources. In Java, parallelism is done using parallel streams, and project Loom is the answer to the problem with concurrency. It’s available since Java 19 in September 2022 as a preview feature. Its goal is to dramatically reduce the effort of writing, maintaining, and observing high-throughput concurrent applications.

“Conservative was first — they are not looking to upset any of the existing Java programmers with features that are going to break a lot of what they do. But they are looking to do some innovation.” This week’s Java 20 release revised two Project Loom java virtual threads features that experts expect to have far-reaching effects on the performance of Java apps, should they become standard in September’s long-term support version. We very much look forward to our collective experience and feedback from applications.

Benefits of Lightweight Threads in Java

Obviously, Java is used in many other areas, and the ideas introduced by Loom may well be useful in these applications. It’s easy to see how massively increasing thread efficiency, and dramatically reducing the resource requirements for handling multiple competing needs, will result in greater throughput for servers. Better handling of requests and responses is a bottom-line win for a whole universe of existing and to-be-built Java applications. An important note about Loom’s fibers is that whatever changes are required to the entire Java system, they are not to break existing code. Existing threading code will be fully compatible going forward. As you can imagine, this is a fairly Herculean task, and accounts for much of the time spent by the people working on Loom.

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.

Learn more about Java, multi-threading, and Project Loom

For more details on the features in Java 21, please read the Java 21 technical blog post. To answer these questions you must understand the thread-per-request model. When a request is handled by the web server it is using a Java Thread and that thread is tied to an operating system thread. When you make a call to a blocking operation like reading or persisting to a database that thread is blocked from doing anything else until the request is fulfilled.

First, a platform thread needs to store its call stack in memory. The first one is to enable server applications written in the simple thread-per-request style to scale with near-optimal hardware utilisation. Ironically, the threads invented to virtualize scarce computational resources for the purpose of transparently sharing them, have themselves become scarce resources, and so we’ve had to erect complex scaffolding to share them.

Virtual threads

Virtual threads should never be pooled, since each is intended to run only a single task over its lifetime. We have removed many uses of thread locals from the java.base module in preparation for virtual threads, to reduce memory footprint when running with millions of threads. When these features are production ready, it will be a big deal for libraries and frameworks that use threads or parallelism.