It's pretty easy to simulate that with a bit of mutable private state.
Project Loom: Fibers and Continuations for the Java Virtual Machine
31–40 of 43 posts
Re: Project Loom: Fibers and Continuations for the Java Virtual Machine
#32Earlier quoted context omitted.
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 pr…
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.
Re: Project Loom: Fibers and Continuations for the Java Virtual Machine
#33Adding 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/
Re: Project Loom: Fibers and Continuations for the Java Virtual Machine
#34Earlier quoted context omitted.
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.
Re: Project Loom: Fibers and Continuations for the Java Virtual Machine
#35Is this something similar to a Goroutine?
Yes.
Re: Project Loom: Fibers and Continuations for the Java Virtual Machine
#36Pretty 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.
Re: Project Loom: Fibers and Continuations for the Java Virtual Machine
#37Async/await would be fantastic in Java. Unfortunately they don’t seem to be a fan.
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.
Re: Project Loom: Fibers and Continuations for the Java Virtual Machine
#38Earlier quoted context omitted.
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...
Re: Project Loom: Fibers and Continuations for the Java Virtual Machine
#39Earlier quoted context omitted.
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).
Re: Project Loom: Fibers and Continuations for the Java Virtual Machine
#40Earlier quoted context omitted.
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.