Loom prototype publicly available

Ron Pressler ron.pressler at oracle.com
Wed Aug 8 10:06:34 UTC 2018

Thanks, Martijn! 
That can certainly be a good idea, but at a later point, when we have a better sense of the design. 
I fear that making Loom too accessible at this early stage in the design may cause a barrage of bikeshed suggestions.


On August 7, 2018 at 4:29:52 PM, Martijn Verburg (martijnverburg at gmail.com) wrote:

Hi Ron et al,

Would you like Project Loom builds at AdoptOpenJDK.net?  We build Amber (raw string literals branch).  Happy to add Loom if that suits.


On Fri, 3 Aug 2018 at 01:38, Ron Pressler <ron.pressler at oracle.com> wrote:
Yes, the current implementation is “one shot” (and a one-shot delimited continuation is often also known as a coroutine), and cannot be used to implement amb. However, we may make the continuations cloneable in which case they can be used to implement amb.

On July 30, 2018 at 9:03:16 AM, Ryan Schmitt (rschmitt at pobox.com) wrote:

This is a fascinating prototype. Would it be correct to describe Loom's continuations as "one-shot" continuations? Should it be possible to implement the `amb` operator on this prototype?

On Fri, Jul 27, 2018 at 10:51 AM, Ron Pressler <ron.pressler at oracle.com> wrote:

You can now build and try our initial Loom prototype.

        $ 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)

- 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

Work on tail calls has not yet begun.

Current status will be tracked in a wiki page we will set up soon.

The fibers API is in the java.lang.Fiber class, and is minimal at this stage.
Thread locals should work as expected (and be associated with the fiber), and
calls to Thread.currentThread() would return a consistent result, so a lot of
existing code should work. 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.

The current implementation performs a full stack copy by default. To experiment
with the lazy-copying solution I described in a previous email, add
`-XX:+UnlockExperimentalVMOptions -XX:+UseNewCode`, but note that in that mode
exceptions thrown inside continuations may not work (probably crash the VM) and
stack traces would be missing frames.

This is an initial prototype made to be simple to implement so we could
experiment with different APIs, compatibility etc.. Performance, therefore, is
far from stellar. Designing a good API and writing an implementation with good
performance are our top priorities.

You’re welcome to try the prototype and share your impressions here. On Monday,
we’ll present Loom at JVMLS, and more updates will follow.


More information about the loom-dev mailing list