Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Project Loom: Fibers and Continuations for the Java Virtual Machine

cr.openjdk.java.net

Post reply on HN
Print view View original

21–30 of 43 posts

Re: Project Loom: Fibers and Continuations for the Java Virtual Machine

#21

Post by _Codemonkeyism »

relics443 wrote: post #7
ssijak wrote: post #4

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

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.

Re: Project Loom: Fibers and Continuations for the Java Virtual Machine

#22

Post by Blackthorn »

geodel wrote: post #11
djb_hackernews wrote: post #8

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 ho…

If you look at openjdk mailing list Quasar author has joined Oracle and putting 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.

Re: Project Loom: Fibers and Continuations for the Java Virtual Machine

#23

Post by dullgiulio »

wtetzner wrote: post #20
dboreham wrote: post #16

Earlier quoted context omitted.

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

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

Re: Project Loom: Fibers and Continuations for the Java Virtual Machine

#26

Post by relics443 »

_Codemonkeyism wrote: post #21
relics443 wrote: post #7

Earlier quoted context omitted.

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.

Re: Project Loom: Fibers and Continuations for the Java Virtual Machine

#27

Post by pron »

hyperpape wrote: post #18
zbentley wrote: post #5

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…

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.

Re: Project Loom: Fibers and Continuations for the Java Virtual Machine

#28

Post by _Codemonkeyism »

relics443 wrote: post #26
_Codemonkeyism wrote: post #21

Earlier quoted context omitted.

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

Re: Project Loom: Fibers and Continuations for the Java Virtual Machine

#29

Post by pjmlp »

jgowdy wrote: post #25

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.
Post reply on HN