
Project Loom: Fibers and Continuations for the Java Virtual Machine - setra
http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html
======
djb_hackernews
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
If you look at openjdk mailing list Quasar author has joined Oracle and
putting this proposal.

~~~
djb_hackernews
Thank you for connecting the dots for me. The creator of Pulsar is Ron
Pressler and the author of this proposal.

------
ssijak
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-ul...](https://purelyfunctional.tv/guide/clojure-concurrency-
the-ultimate-guide/)

~~~
relics443
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.

~~~
_Codemonkeyism
"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.

~~~
relics443
I believe the article mentions making the java.io package aware of fibers.

~~~
_Codemonkeyism
Yes you're right, though it would be a miracle - I hope for it ! - if this can
be done without changes to existing code.

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

~~~
hyperpape
Does his rant/paper refer to the 1996 paper, or something else?
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.50....](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.50.4682&rep=rep1&type=pdf)

~~~
pron
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.

~~~
hyperpape
Thanks. I was not meaning to comment on whether Cantrill was right. His name
comes up on this topic, and I wasn't sure whether it all stemmed from that
paper, or if there were further complaints from him.

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

------
andrebask
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/)

------
vvanders
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
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
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
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
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).

~~~
tomp
Yeah, I've considered playing with Quasar, but I'm a bit concerned about the
"colored functions" that it imposes. In any case, I'm mainly interested in
Fibres as a code generation platform (for some toy languages I'm playing
with), and obviously there I could avoid having to use Quasar/bytecode
rewriting by simply emitting functions as state machines in the first place...
My hope for project Loom is to be able to avoid this, i.e. to have it taken
care of automagically by JVM.

~~~
pron
Quasar doesn't have colored functions, and you can instrument your code at
build time, as part of the compilation process. But an implementation in the
JVM is indeed more robust and efficient.

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

~~~
peoplewindow
Yes, it would.

~~~
dboreham
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...](https://en.wikipedia.org/wiki/Green_threads#Green_threads_in_the_Java_virtual_machine)

~~~
wtetzner
> 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
Absolutely, especially if the lightweight threads are implemented on top of OS
threads, which is not what was done with Green Threads.

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

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

~~~
Skinney
Project Loom seems to be much better than async/await. Hopefully they manage
to implement it.

~~~
xstartup
I think async/await is much higher level abstraction than a "fiber", so you
can probably implement async/await on top of fibers.

------
xstartup
Is this something similar to a Goroutine?

~~~
pron
Yes.

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

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

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

