Loom prototype publicly available
duncan.macgregor at oracle.com
duncan.macgregor at oracle.com
Mon Jul 30 17:25:23 UTC 2018
We've done a quick prototype in TruffleRuby.
Christ Seaton has posted a blog about it at
https://medium.com/graalvm/bringing-fibers-to-truffleruby-1b5d2e258953
and I've written about some of the technical details at
https://aardvark179.github.io/blog/fibers.html.
This is all running with TruffleRuby under Graal, and it shows we can
scale the number of fibres very nicely, but we still need to look at
performance.
Duncan.
On 27/07/18 18:51, Ron Pressler 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