13 ms·

Project Loom: Fibers and Continuations for the Java Virtual Machine

112 points by setra 9y ago

s_kilk 9y ago
Would this mean having something in Java like the M:N thread model we see in Go, Erlang, and such?
- peoplewindow 9y ago
  Yes, it would.
  - dboreham 9y ago
    Again. Since it has this long ago, and long ago removed[1] when folks realized that OS-native threads are the way to go if you have them. [1] https://en.wikipedia.org/wiki/Green_threads#Green_threads_in_the_Java_virtual_machine https://en.wikipedia.org/wiki/Green_threads#Green_threads_in...
    - wtetzner 9y ago
      > when folks realized that OS-native threads are the way to go if you have them. Well, it depends on what you're trying to do. Having the option of using either is preferable.
      - dullgiulio 9y ago
        Absolutely, especially if the lightweight threads are implemented on top of OS threads, which is not what was done with Green Threads.
    - dragonwriter 9y ago
      Old Java threads were 1:N, not M:N, and were instead of rather than in addition to support for 1:1 native threads. Having the choice between 1:1 and M:N both available on the platform is better than being locked into 1:1 or 1:N (or even M:N.) What is offered here is strictly better than the current or previous state.
tcgarvin 9y ago
Relevant mailing list discussion: http://mail.openjdk.java.net/pipermail/discuss/2017-September/004390.html http://mail.openjdk.java.net/pipermail/discuss/2017-Septembe...
ssijak 9y ago
There are already many different libraries or approaches to concurrency and parallelism on JVM. - http://www.baeldung.com/java-completablefuture http://www.baeldung.com/java-completablefuture Promises - http://vertx.io/ http://vertx.io/ Event Loop - https://akka.io/ https://akka.io/ and http://www.paralleluniverse.co/quasar/ http://www.paralleluniverse.co/quasar/ Actors - https://projectreactor.io/ https://projectreactor.io/ and https://github.com/ReactiveX/RxJava https://github.com/ReactiveX/RxJava Reactive, event-based - https://kotlinlang.org/docs/reference/coroutines.html https://kotlinlang.org/docs/reference/coroutines.html Kotlin coroutines. Something like Project Loom from what I gathered from the article. Can be easily used as lightweight threads, async/await, actors, etc. - Clojure with its own mix https://purelyfunctional.tv/guide/clojure-concurrency-the-ultimate-guide/ https://purelyfunctional.tv/guide/clojure-concurrency-the-ul...
- tomp 9y ago
  Actually, Quasar is more than actors - it also implements true, actual fibers/coroutines, using bytecode rewriting (essentially turning each async function into a state machine).
- relics443 9y ago
  My understanding of all these projects is that you have to change your style of coding / have more complex APIs, or they're just syntactic sugar over heavyweight threads. What loom seems to offer is the best of both worlds; going back to writing simpler code (e.g. regular "blocking" io code) while scaling much better.
  - SureshG 9y ago
    > have more complex APIs, or they're just syntactic sugar over heavyweight threads. I am pretty sure that's not the case with Kotlin coroutines :)
  - _Codemonkeyism 9y ago
    "blocking" io code would be blocking. Every IO library would need to migrate to something non blocking. This might happen with some - currently some use Netty and NIO - but e.g. JDBC drivers are synchronous.
zbentley 9y ago
This is an excellent introduction not only to work being done on the JVM, but on some of the implementation challenges of userspace concurrency/greenthreads and M:N scheduling in general. The detail, nuance, and humility present in this article give me some hope that pathological misbehavior of other M:N scheduling models (see Bryan Cantrill's rant/paper about this for more info) may be avoided if something like that comes to the JVM. However, the sheer complexity of the existing JVM code, as the authors point out, may present an obstacle to that quality. Figuring out yield points for coroutines across a large java codebase seems like it would be . . . painful, to say the least.
- dboreham 9y ago
  Executive summary : It will probably all end in tears. It would be nice just to have TLS that works with NIO[2].
  - deleted 9y ago
    [deleted]
- hyperpape 9y ago
  Does his rant/paper refer to the 1996 paper, or something else? http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.50.4682&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.50....
  - pron 9y ago
    I wrote the proposal, and I did not mention this paper because that would be going into too much detail. However: 1. The paper discusses an implementation of lightweight threads in cooperation with the kernel, in a way that requires switching back and forth between user and kernel mode. 2. The paper was written before the advent of work-stealing schedulers (first popularized in Cilk). Work stealing schedulers have proven themselves to be very efficient for scheduling lightweight threads that block often (on IO or communication with other threads), and have been used with great success in both Erlang and Go. They address the scheduling problems discussed in the paper.
djb_hackernews 9y ago
I skimmed the article but this seems heavily influenced by Quasar http://docs.paralleluniverse.co/quasar/ http://docs.paralleluniverse.co/quasar/ but doesn't make any mention of it. I have some experience with it and I found it to be a very well designed and documented API. I hope to see it in the JVM someday. The person behind it is pretty active online and does some other interesting things (the TLA+ subreddit), not sure if they are an hn reader but I hope they chime in here.
- geodel 9y ago
  If you look at openjdk mailing list Quasar author has joined Oracle and putting this proposal.
  - djb_hackernews 9y ago
    Thank you for connecting the dots for me. The creator of Pulsar is Ron Pressler and the author of this proposal.
  - Blackthorn 9y ago
    Ah, that explains why quasar development has been idle for a while, after the jdk9 release. I can't wait to see this in Java proper, quasar is pretty magical and I was looking forward to seeing it extended to all jvm languages transparently.
xstartup 9y ago
Is this something similar to a Goroutine?
- pron 9y ago
  Yes.
brodock 9y ago
JRuby people will love to have Fibers natively supported by the JVM
vvanders 9y ago
Pretty disappointed that continuations won't be able to yield a value(s). That was one of the most powerful things about Lua's coroutines. Back in games we'd use the yield value as the number of frames to skip before rescheduling giving a really nice coarse grained control over coroutine execution. It also opens up lazy sequences and all sort of other really useful things.
- tomp 9y ago
  Are you sure? One of their examples includes code like this: produce 1 fiber sleep 100ms suggesting that at least they're aware of its usefulness. In any case, it's pretty easy to simulate that with a bit of mutable private state.
  - pron 9y ago
    That's correct (I wrote the proposal). There will be two-way communication between the entry (reset) and yield (shift) site, but this may be implemented in Java in the JDK libraries on top of a lower-level construct in the JVM, if not in the JVM itself.
    - tomp 9y ago
      You wrote the proposal? Amazing! Any clue when it might get implemented, or how might I experiment with it before it's part of the official HotSpot release? I think fibers would really bring JVM to the next level...
      - pron 9y ago
        Once the voting period is complete, in another week, there will be a mailing list for the project. We'll publish binaries from time to time for people to try. In the meantime, you can play with Quasar, to see if you like the model (although as Loom would be implemented in the JVM, we expect it to be more robust, more efficient and even more convenient).
        9y ago
bullen 9y ago
Again, NIO and real multi-threading (across cores with shared memory) is really what you want to use. It's scary, but I've done all the hard parts: http://github.com/tinspin/rupy http://github.com/tinspin/rupy
jgowdy 9y ago
Async/await would be fantastic in Java. Unfortunately they don’t seem to be a fan.
- pjmlp 9y ago
  From my experience in .NET with them, one issue I have with async/await vs direct use of TPL is how they infect the whole source code, if you want to properly use them.
- Skinney 9y ago
  Project Loom seems to be much better than async/await. Hopefully they manage to implement it.
  - xstartup 9y ago
    I think async/await is much higher level abstraction than a "fiber", so you can probably implement async/await on top of fibers.
susankim 9y ago
It's pretty easy to simulate that with a bit of mutable private state.
- oweiler 9y ago
  No it's not. User-level threads are currently not supported in Java.
andrebask 9y ago
Adding continuations to the JVM would be really useful for JVM language designer. I worked on this topic a couple of years ago for my MSc thesis, I implemented continuations exploiting the exception mechanism, this made implementing async/await relatively easy https://andrebask.github.io/thesis/ https://andrebask.github.io/thesis/

112 points by setra 9y ago

s_kilk 9y ago

Would this mean having something in Java like the M:N thread model we see in Go, Erlang, and such?

peoplewindow 9y ago
Yes, it would.
- dboreham 9y ago
  Again. Since it has this long ago, and long ago removed[1] when folks realized that OS-native threads are the way to go if you have them. [1] https://en.wikipedia.org/wiki/Green_threads#Green_threads_in_the_Java_virtual_machine https://en.wikipedia.org/wiki/Green_threads#Green_threads_in...
  - wtetzner 9y ago
    > when folks realized that OS-native threads are the way to go if you have them. Well, it depends on what you're trying to do. Having the option of using either is preferable.
    - dullgiulio 9y ago
      Absolutely, especially if the lightweight threads are implemented on top of OS threads, which is not what was done with Green Threads.
  - dragonwriter 9y ago
    Old Java threads were 1:N, not M:N, and were instead of rather than in addition to support for 1:1 native threads. Having the choice between 1:1 and M:N both available on the platform is better than being locked into 1:1 or 1:N (or even M:N.) What is offered here is strictly better than the current or previous state.

tcgarvin 9y ago

Relevant mailing list discussion: http://mail.openjdk.java.net/pipermail/discuss/2017-September/004390.html http://mail.openjdk.java.net/pipermail/discuss/2017-Septembe...

ssijak 9y ago

There are already many different libraries or approaches to concurrency and parallelism on JVM. - http://www.baeldung.com/java-completablefuture http://www.baeldung.com/java-completablefuture Promises - http://vertx.io/ http://vertx.io/ Event Loop - https://akka.io/ https://akka.io/ and http://www.paralleluniverse.co/quasar/ http://www.paralleluniverse.co/quasar/ Actors - https://projectreactor.io/ https://projectreactor.io/ and https://github.com/ReactiveX/RxJava https://github.com/ReactiveX/RxJava Reactive, event-based - https://kotlinlang.org/docs/reference/coroutines.html https://kotlinlang.org/docs/reference/coroutines.html Kotlin coroutines. Something like Project Loom from what I gathered from the article. Can be easily used as lightweight threads, async/await, actors, etc. - Clojure with its own mix https://purelyfunctional.tv/guide/clojure-concurrency-the-ultimate-guide/ https://purelyfunctional.tv/guide/clojure-concurrency-the-ul...

tomp 9y ago
Actually, Quasar is more than actors - it also implements true, actual fibers/coroutines, using bytecode rewriting (essentially turning each async function into a state machine).
relics443 9y ago
My understanding of all these projects is that you have to change your style of coding / have more complex APIs, or they're just syntactic sugar over heavyweight threads. What loom seems to offer is the best of both worlds; going back to writing simpler code (e.g. regular "blocking" io code) while scaling much better.
- SureshG 9y ago
  > have more complex APIs, or they're just syntactic sugar over heavyweight threads. I am pretty sure that's not the case with Kotlin coroutines :)
- _Codemonkeyism 9y ago
  "blocking" io code would be blocking. Every IO library would need to migrate to something non blocking. This might happen with some - currently some use Netty and NIO - but e.g. JDBC drivers are synchronous.

zbentley 9y ago

This is an excellent introduction not only to work being done on the JVM, but on some of the implementation challenges of userspace concurrency/greenthreads and M:N scheduling in general. The detail, nuance, and humility present in this article give me some hope that pathological misbehavior of other M:N scheduling models (see Bryan Cantrill's rant/paper about this for more info) may be avoided if something like that comes to the JVM. However, the sheer complexity of the existing JVM code, as the authors point out, may present an obstacle to that quality. Figuring out yield points for coroutines across a large java codebase seems like it would be . . . painful, to say the least.

dboreham 9y ago
Executive summary : It will probably all end in tears. It would be nice just to have TLS that works with NIO[2].
- deleted 9y ago
  [deleted]
hyperpape 9y ago
Does his rant/paper refer to the 1996 paper, or something else? http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.50.4682&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.50....
- pron 9y ago
  I wrote the proposal, and I did not mention this paper because that would be going into too much detail. However: 1. The paper discusses an implementation of lightweight threads in cooperation with the kernel, in a way that requires switching back and forth between user and kernel mode. 2. The paper was written before the advent of work-stealing schedulers (first popularized in Cilk). Work stealing schedulers have proven themselves to be very efficient for scheduling lightweight threads that block often (on IO or communication with other threads), and have been used with great success in both Erlang and Go. They address the scheduling problems discussed in the paper.

djb_hackernews 9y ago

I skimmed the article but this seems heavily influenced by Quasar http://docs.paralleluniverse.co/quasar/ http://docs.paralleluniverse.co/quasar/ but doesn't make any mention of it. I have some experience with it and I found it to be a very well designed and documented API. I hope to see it in the JVM someday. The person behind it is pretty active online and does some other interesting things (the TLA+ subreddit), not sure if they are an hn reader but I hope they chime in here.

geodel 9y ago
If you look at openjdk mailing list Quasar author has joined Oracle and putting this proposal.
- djb_hackernews 9y ago
  Thank you for connecting the dots for me. The creator of Pulsar is Ron Pressler and the author of this proposal.
- Blackthorn 9y ago
  Ah, that explains why quasar development has been idle for a while, after the jdk9 release. I can't wait to see this in Java proper, quasar is pretty magical and I was looking forward to seeing it extended to all jvm languages transparently.

xstartup 9y ago

Is this something similar to a Goroutine?

pron 9y ago
Yes.

brodock 9y ago

JRuby people will love to have Fibers natively supported by the JVM

vvanders 9y ago

Pretty disappointed that continuations won't be able to yield a value(s). That was one of the most powerful things about Lua's coroutines. Back in games we'd use the yield value as the number of frames to skip before rescheduling giving a really nice coarse grained control over coroutine execution. It also opens up lazy sequences and all sort of other really useful things.

tomp 9y ago
Are you sure? One of their examples includes code like this: produce 1 fiber sleep 100ms suggesting that at least they're aware of its usefulness. In any case, it's pretty easy to simulate that with a bit of mutable private state.
- pron 9y ago
  That's correct (I wrote the proposal). There will be two-way communication between the entry (reset) and yield (shift) site, but this may be implemented in Java in the JDK libraries on top of a lower-level construct in the JVM, if not in the JVM itself.
  - tomp 9y ago
    You wrote the proposal? Amazing! Any clue when it might get implemented, or how might I experiment with it before it's part of the official HotSpot release? I think fibers would really bring JVM to the next level...
    - pron 9y ago
      Once the voting period is complete, in another week, there will be a mailing list for the project. We'll publish binaries from time to time for people to try. In the meantime, you can play with Quasar, to see if you like the model (although as Loom would be implemented in the JVM, we expect it to be more robust, more efficient and even more convenient).
      - 9y ago

bullen 9y ago

Again, NIO and real multi-threading (across cores with shared memory) is really what you want to use. It's scary, but I've done all the hard parts: http://github.com/tinspin/rupy http://github.com/tinspin/rupy

jgowdy 9y ago

Async/await would be fantastic in Java. Unfortunately they don’t seem to be a fan.

pjmlp 9y ago
From my experience in .NET with them, one issue I have with async/await vs direct use of TPL is how they infect the whole source code, if you want to properly use them.
Skinney 9y ago
Project Loom seems to be much better than async/await. Hopefully they manage to implement it.
- xstartup 9y ago
  I think async/await is much higher level abstraction than a "fiber", so you can probably implement async/await on top of fibers.

susankim 9y ago

It's pretty easy to simulate that with a bit of mutable private state.

oweiler 9y ago
No it's not. User-level threads are currently not supported in Java.

andrebask 9y ago

Adding continuations to the JVM would be really useful for JVM language designer. I worked on this topic a couple of years ago for my MSc thesis, I implemented continuations exploiting the exception mechanism, this made implementing async/await relatively easy https://andrebask.github.io/thesis/ https://andrebask.github.io/thesis/