
Loom prototype available – fibers and delimited continuations for the JVM - spullara
http://mail.openjdk.java.net/pipermail/loom-dev/2018-July/000061.html
======
chrisseaton
Here's a couple of early studies of using it:

[https://aardvark179.github.io/blog/fibers.html/](https://aardvark179.github.io/blog/fibers.html/)

[https://medium.com/graalvm/bringing-fibers-to-
truffleruby-1b...](https://medium.com/graalvm/bringing-fibers-to-
truffleruby-1b5d2e258953)

------
kodablah
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.

------
exabrial
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)

~~~
spullara
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](https://news.ycombinator.com/item?id=6977914)

~~~
BenoitP
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](https://youtu.be/J31o0ZMQEnI?t=25m10s)

------
spullara
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.

~~~
dang
Ok, we'll add that phrase back above.

