Warning | ||
---|---|---|
| ||
Loom is under active development, which means that information and advice given here might change in the future. |
Table of Contents |
---|
Supported Platforms
Mac and Linux on x86-64
Download and Build from Source
Code Block |
---|
$ hg clone http://hg.openjdk.java.net/loom/loom $ cd loom $ hg update -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. The construct is exposed via the java.lang.Continuation
class. Continuations are intended as a low-level API, that application authors are not intended to use directly. They will use higher-level constructs built on top of continuations, such as fibers or generators.
A continuation object is constructed by passing two arguments to the constructor: a Runnable
target that serves as the body of the continuation, and a java.lang.ContinuationScope
. The scope is the delimited continuation's prompt, that allows continuations to be nested. One could think of such "scoped continuations" as nested try/catch
blocks, where the scope is the type of the exception thrown, which determines the handler called.
A continuation is started by calling Continuation.run
, which would start executing the body in the continuation's target, and returns either when the continuation terminates (the body runs to completion, and terminates either normally or abnormally), or when it yields on the continuation's scope. To query the reason for run
returning, use Continuation.isDone
, which returns true
if the body has terminated, or false
if it has yielded.
A call to the static Continuation.yield
suspends the current continuation and all enclosing continuations up until the innermost one with the scope passd to yield
, causing the run
method of that continuation to return.
The Continuation
class does not provide a mechanism of communication between run
and yield
(i.e., neither takes or returns a value that is passed to/received from the other), unlike most implementations of delimited continuations. However, implementing a class that does allow this kind of communication on top of the Continuation
class is straightforward, and will likely be included in the JDK.
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
Fibers are implemented in the core libraries. A fiber is implemented as a continuation (of fiber scope) that is wrapped as a task and scheduled by a j.u.c.Executor
.
Tail Calls
Design
We envision tail-call elimination that pops one or perhaps even an arbitrary number of stack frames at explicitly marked call-sites. It is not the intention of this project to implement automatic tail-call optimization.
Implementation
The implementation of this feature requires cross-cutting changes to the VM, VM specification (bytecode), and possibly the front-end Java compiler (javac). As a result, in order not to delay the completion of continuations and fibers, we will only begin specifying and implementing this feature only when the project is at a more advanced phase.