4 ms·

Loom prototype available – fibers and delimited continuations for the JVM

52 points by spullara 8y ago

spullara 8y ago
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 8y ago
  Ok, we'll add that phrase back above.
chrisseaton 8y ago
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-1b5d2e258953 https://medium.com/graalvm/bringing-fibers-to-truffleruby-1b...
kodablah 8y ago
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 8y ago
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 8y ago
  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 8y ago
    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

52 points by spullara 8y ago

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 8y ago
Ok, we'll add that phrase back above.

chrisseaton 8y ago

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-1b5d2e258953 https://medium.com/graalvm/bringing-fibers-to-truffleruby-1b...

kodablah 8y ago

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 8y ago

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 8y ago
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 8y ago
  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