I skimmed the article but this seems heavily influenced by 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.

If you look at openjdk mailing list Quasar author has joined Oracle and putting this proposal.

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

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.

There are already many different libraries or approaches to concurrency and parallelism on JVM.

- http://www.baeldung.com/java-completablefuture Promises

- http://vertx.io/ Event Loop

- https://akka.io/ and http://www.paralleluniverse.co/quasar/ Actors

- https://projectreactor.io/ and https://github.com/ReactiveX/RxJava Reactive, event-based

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

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

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.

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

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

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

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

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.

Does his rant/paper refer to the 1996 paper, or something else? http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.50....

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.

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.

Executive summary : It will probably all end in tears.

It would be nice just to have TLS that works with NIO[2].

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

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/

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.

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.

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.

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

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

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.

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.

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

Yes, it would.

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

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.

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

Absolutely, especially if the lightweight threads are implemented on top of OS threads, which is not what was done with Green Threads.

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

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

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.

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

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

Is this something similar to a Goroutine?

Yes.

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

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

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