Loom is under active development, which means that information and advice given here might change in the future.
Mac and Linux on x86-64
Download and Build from Source
$ git clone https://github.com/openjdk/loom $ cd loom $ git checkout fibers $ sh configure $ make images
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
jtreg(the JDK test harness) and place its
binsubdirectory on your path.
Create a debug JDK configuration (inside the top directory of the Loom repo) and build it. This step requires having
jtregon your path, or running the tests would fail:
$ sh configure --with-jtreg --with-debug-level=fastdebug $ make images
Run the tests. The following example assumes a Mac build (replace
linuxfor a Linux build), and the
java/lang/Continuation/Basic.javatest, which contains some basic
java/lang/Continuationdirectory contains Continuation test, while the
java/lang/Continuationdirectory contains fiber tests. Supplying just the directory name runs all tests in the directory.
$ make run-test TEST=open/test/jdk/java/lang/Continuation/Basic.java CONF=macosx-x86_64-server-fastdebug
See JEP 425: Virtual Threads (Preview)
Virtual threads are implemented in the core libraries. A virtual thread is implemented as a continuation 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.
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.
See the Virtual Thread Debugging Support page.
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 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, 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.
We envision explicit tail-call elimination. It is not the intention of this project to implement automatic tail-call optimization.