Loom prototype publicly available
Ron Pressler
ron.pressler at oracle.com
Fri Jul 27 18:37:00 UTC 2018
P.S.
As Project Loom is in its early stages, I must emphasize that everything
pertaining to APIs and various features (such as the behavior of
Thread.currentThread(), thread locals, Object.wait() etc.) merely describes the
behavior of this initial prototype and is subject to change. This prototype is
meant to serve as an initial subject for design discussion, rather than any
finalized design.
In order to test some ideas in the prototype, we preferred an approach that
would allow us to run more existing code at the cost of designing the "right"
API and behavior. What that right behavior is will be our topic of discussion in
the coming months.
R
On July 27, 2018 at 6:51:31 PM, Ron Pressler (ron.pressler at oracle.com(mailto: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