Loom prototype publicly available

Stephane Epardaud stef at epardaud.fr
Mon Jul 30 15:38:02 UTC 2018


Hi,

That's pretty great. I tried it out by porting Redpipe
(http://redpipe.net/index.html#fibers) from Quasar to it and it works
just as well: all tests pass.

So now I have Quasar for JDK<9 and Loom for JDK>11 and nothing in the
middle :(

Note that I've also successfully tested suspending iterables
(suspending/parking within Iterator.next() inside a for-each) and it
Just Works.

Great work!

I do think that you should flesh out javadoc a little more than TBD
(doesn't need to be more than one sentence) ;)

Oh, and why Strand.currentStrand() and not Fiber.currentFiber()?

Also, any estimate as to which Java version this is going to be merged in?


On 27/07/18 19: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