Loom prototype available – fibers and delimited continuations for the JVM | Hacker News Reader

Loom prototype available – fibers and delimited continuations for the JVM

mail.openjdk.java.net

52 pointsspullara7 comments

Here's a couple of early studies of using it:

https://aardvark179.github.io/blog/fibers.html/

https://medium.com/graalvm/bringing-fibers-to-truffleruby-1b...

Kotlin's coroutines are just coming out of beta, I hope they will be able to leverage this work for easy interop if the Java version with loom is targeted. I understand it's early days, I just don't want to rework anything, and I'm sure the same compat question exists for Quasar.

This is cool!! I wish the jvm could take the thread class and optimise this for you (switching between green threads and posix threads automatically)

The Solaris JVM from 20 years ago had an N:M green threads system. It doesnt work that well in practice when it is implicit. Some HN discussion when Rust decided to stick to native threads.

https://news.ycombinator.com/item?id=6977914

The comment you point to seems like an argument that the JVM could be a good environment to the green threads:

> Building a correct highly concurrent scheduler is no easy task

I've been hearing that Java's ForkJoinPool is up to the task, and works well with Java's locking infrastructure.

> now can't have work stealing between your native threads

Indeed that is a concern, but as long as native stack frames make you fall back to regularly preempting an OS thread, the program will run. You're not having the performance boost for this workload, but your program does not crash; and is ready for some refactoring inside greenthread managed execution. This seems to be the current behavior of the Loom prototype.

> Next thing you realize is that you're still spending lots of memory on creating stacks for your green threads

We might be at the point where library writers can choose where to draw the line about stack, where and what to serialize. This is enabled by the delimited continuations.

> is that regular blocking IO (better yet mmaped IO) outperforms what most people are capable of achieving using the non-blocking disk IO facilities.

This calls for it to be managed inside the Standard Library.

----

Another comment down the line talks about a successful implementation in Erlang; with overhead size at 284 bytes. The current prototype has it at 200-240 [1], so this is already a win.

Coupled with the java.util.concurrent and Locks, I think it will go way beyond what Erlang is capable of. Message passing mandates copying and restricts code styles. And on top of that the JIT will bring in efficient CPU usage.

[1] https://youtu.be/J31o0ZMQEnI?t=25m10s

Loom is the code name for the project to add fibers and delimited continuations to the JVM. That was in the title I set and the original title is accurate but not very informative.

Ok, we'll add that phrase back above.

Reply on news.ycombinator.com