Loom prototype publicly available

Simon Basle sbasle at pivotal.io
Tue Aug 7 16:03:49 UTC 2018


Great to have something to play with, Ron, thanks for putting that
prototype out.

My thoughts and questions probably fall in the "this is an early prototype,
just wait" category, but here goes nothing:

 - has there been any further decision regarding `Fiber.execute(Callable)`,
ie running a computation that returns a value, inside a Fiber?

 - is there a particular rationale behind `Fiber#awaitNanos(long)` to
return the `Fiber` itself, rather than a boolean? This prevent from finding
out wether or not the timeout was triggered.

Cheers,
Simon



> On Fri, Jul 27, 2018 at 10:51 AM, Ron Pressler <ron.pressler at oracle.com>
> wrote:
> Hi.
>
> 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.
>
>
> Ron
>
>
>
>
>


More information about the loom-dev mailing list