Project Loom: A trend to watch in the JVM ecosystem
Project Loom was introduced last year and now the initial prototype is publicly available. The goal of this project is to add a new concurrency tool to the Java toolkit: fibers. Let’s have a closer look at this project.
There are many new initiatives on the JVM, starting with Amber and Valhalla, two projects that a lot of people are looking forward to seeing in action, Panama, Metropolis, GraalVM, and Loom, to name a few. We’ve already talked about some of them, now it’s time to introduce Loom, which aims to make concurrency more granular.
According to the project proposal, Loom introduces “fibers as lightweight, efficient threads managed by the Java Virtual Machine, that let developers use the same simple abstraction but with better performance and lower footprint.”
As John Rose, JVM Architect at Oracle explained at FOSDEM earlier this year, the idea behind Loom is to “work around ‘dinosaur threads'”. This means:
- Breaking the live bits into smaller parts
- Leaving behind the fossils
The main goal of this project is to add a lightweight thread construct, which we call fibers, managed by the Java runtime, which would be optionally used alongside the existing heavyweight, OS-provided, implementation of threads.
The difference between fibers and kernel threads is that the former are more lightweight in terms of memory footprint, and the overhead of task-switching among them is close to zero. A thread consists of a scheduler and a continuation but, as shown in the proposal, the intent is to separate them and implement Java fibers on top of those two building blocks. Even though fibers represent the project’s main motivation for this project, it is also important to add continuations as a user-facing abstraction, as continuations have other uses, too (e.g. Python’s generators).
Read the project proposal here.
Loom prototype publicly available
Ron Pressler, Project Loom lead, recently announced the availability of the initial Loom prototype.
$ hg clone http://hg.openjdk.java.net/loom/loom
$ cd loom
$ hg update -r fibers
$ sh configure
$ make images
Keep in mind that you have to switch to the fibers branch.
More details about the work so far:
- Supported platforms: Mac and Linux on x86-64
- Tested GCs: Parallel and G1
- Supported compilers: C1, C2, Graal
- Missing features: JVM TI (fiber debugging), fiber/continuation serialization
The wiki page has not been set up yet but it’s going to happen soon.
As Pressler explained, “the fibers API is in the java.lang.Fiber class” but right now it is minimal. There shouldn’t be any problems as far as thread locals are concerned, and calls to Thread.currentThread() would return a consistent result, so a lot of existing code should work. Furthermore, “most relevant IO operations, as well as java.util.concurrent constructs, Thread.sleep etc. will now result in the fiber — rather than the underlying kernel thread — being blocked.”
Object.wait() would still block the underlying kernel thread, as would trying to park a fiber while a native monitor is held or a native method is on the stack.
– Ron Pressler
Although performance is “far from stellar” at the moment, they are dedicated to “designing a good API and writing implementation with good performance.” It is also important to understand that the prototype serves as an initial subject for design discussion so everything related to APIs and various features (such as the behavior of Thread.currentThread(), thread locals, Object.wait() etc.) is subject to change.
Learn more about the initial Loom prototype here.