Page History

Image Added

Loom

 Fibers, Continuations and Tail-Calls

Table of Contents

Supported Platforms

Mac and Linux on x86-64

Download and Build from Source

$ hggit clone httphttps://hggithub.openjdk.java.net/loomcom/openjdk/loom  
$ cd loom  
$ hggit updatecheckout -r fibers 
$ sh configure   
$ make images

(Note that you must switch to the fibers branch before building)

Missing Features

• JVM TI support (fiber debugging)

• Forced preemption

• Cloning continuations

• Serialization of fiber/continuation

   

Continuations

Design

The primitive continuation construct is that of a scoped (AKA multiple-named-prompt), stackful, one-shot (non-reentrant) delimited continuation. The continuation can be cloned, and thus used to implement reentrant delimited continuations.

Implementation

Performance

Current yield/continue performance is far from stellar. The reason is that we focused on getting a working prototype using existing Hotspot mechanisms, some of which have not been designed to be used so frequently. We are now working on improving performance both by optimizing the actual freeze/thaw logic, as well as optimizing those existing VM mechanisms. 

One mechanism that is particularly slow is the one used to detect whether a frame is holding a native monitor (synchronized block). Because this mechanism is so slow, the monitor detection can be turned off (which will break fiber code that runs through synchronized blocks) by adding -XX:-DetectLocksInCompiledFrames to the java command line.

An important performance feature is lazy-copying of frames. This feature is currently turned off by default because it is missing some important functionality, in particular it does not support the throwing of exceptions, and stack traces will miss some frames (those that have not been thawed). To turn lazy copying on, add -XX:+UnlockExperimentalVMOptions -XX:+UseNewCode to the java command line.

Fibers

Design

Implementation

How to Contribute

The most valuable way to contribute at this time is to try out the current prototype and provide feedback and bug reports to the loom-dev mailing list.  In particular, we welcome feedback that includes a brief write-up of experiences adapting existing libraries and frameworks to work with Fibers.

If you have a login on the JDK Bug System then you can also submit bugs directly. We plan to use an Affects Version/s value of "repo-loom" to track bugs.

How to run the JDK tests

1. Download jtreg (the JDK test harness) and place its bin subdirectory on your path.
   
   

2. Create a debug JDK configuration (inside the top directory of the Loom repo) and build it. This step requires having jtreg on your path, or running the tests would fail:
   

   Code Block
   $ sh configure --with-jtreg --with-debug-level=fastdebug $ make images

   
   

3. Run the tests. The following example assumes a Mac build (replace macosx with linux for a Linux build), and the java/lang/Continuation/Basic.java test, which contains some basic Continuation tests. The java/lang/Continuation directory contains Continuation test, while the java/lang/Continuation directory contains fiber tests. Supplying just the directory name runs all tests in the directory.

   Code Block
   $ make run-test TEST=open/test/jdk/java/lang/Continuation/Basic.java CONF=macosx-x86_64-server-fastdebug

Virtual Threads

Design

See JEP 425: Virtual Threads (Preview)

Implementation

Virtual threads Fibers are implemented in the core libraries. A fiber virtual thread is implemented as a continuation (of fiber scope) that is wrapped as a task and scheduled by a j.u.c.Executor. Parking (blocking) a virtual thread results in yielding its continuation, and unparking it results in the continuation being resubmitted to the scheduler. The scheduler worker thread executing a virtual thread (while its continuation is mounted) is called a carrier thread.

Tail Calls

Design

The continuations used in the virtual thread implementation override onPinned so that if a virtual thread attempts to park while its continuation is pinned (see above), it will block the underlying carrier thread.

The implementation of the networking APIs in the java.net and java.nio.channels  packages have as been updated so that virtual threads doing blocking I/O operations park, rather than block in a system call, when a socket is not ready for I/O. When a socket is not ready for I/O it is registered with a background multiplexer thread. The virtual thread is then unpacked when the socket is ready for I/O.

Debugging

See the Virtual Thread Debugging Support page.

Continuations

Design

The primitive continuation construct is that of a scoped (AKA multiple-named-prompt), stackful, one-shot (non-reentrant) delimited continuation. To implement reentrant delimited continuations, we could make the continuations cloneable. Continuations aren't exposed as a public API, as they're unsafe (they can change Thread.currentThread() mid-method). However, higher level public constructs, such as virtual threads or (thread-confined) generators will make internal use of them.

Tail Calls

Design

We envision explicit tail-call elimination. It is not the intention of this project to implement automatic tail-call optimization.