3 ms·

https://wiki.openjdk.java.net/display/loom/ https://wiki.openjdk.java.net/display/loom/ which is superior to async/await, if I may say so myself (I'm the projec

by pron 8y ago

https://wiki.openjdk.java.net/display/loom/ https://wiki.openjdk.java.net/display/loom/ which is superior to async/await, if I may say so myself (I'm the project lead)

yawaramin 8y ago
> Fibers are user-mode lightweight threads that allow synchronous (blocking) code to be efficiently scheduled, so that it performs as well as asynchronous code Sounds a lot like Erlang BEAM processes.
- pron 8y ago
  Yep; or Go's goroutines. Except that the fibers are implemented and scheduled in the Java libraries; the VM only provides continuations.
  - mycall 8y ago
    How does it compare to Windows fibers?
cozos 8y ago
I find this really interesting. Care to provide some comparisons?
MaxBarraclough 8y ago
Great article, thanks. Some perhaps-silly questions: 1. Is it possible to inspect the state of a 'parking' operation, the way you can in .Net with Task#Status? 2. So fibers run in 'carrier threads'. Is there a pool of carrier threads, or can any thread act as a carrier? I'm thinking of .Net's where this is configurable (ignoring that .Net 'contexts' aren't exactly threads), by means of Task#ContinueWith() and the Scheduler class. I take it from the following snippets that fibers can only run on the thread where they were created: starting or continuing a continuation mounts it and its stack on the current thread – conceptually concatenating the continuation's stack to the thread's – while yielding a continuation unmounts or dismounts it. And also: Parking (blocking) a fiber results in yielding its continuation, and unparking it results in the continuation being resubmitted to the scheduler. On a non-technical note, how do OpenJDK projects feed back into the Java spec and Oracle Java?
- pron 8y ago
  1. Yes. 2. Configurable. A fiber is assigned to a scheduler that is, at least currently, and Executor (so you can implement your own). > I take it from the following snippets that fibers can only run on the thread where they were created No. A fiber has no special relationship to the thread (or fiber) that created it, although now there can be a supervision hierarchy thanks to structured concurrency: https://wiki.openjdk.java.net/display/loom/Structured+Concurrency https://wiki.openjdk.java.net/display/loom/Structured+Concur... > OpenJDK projects feed back into the Java spec and Oracle Java? OpenJDK is the name of the Java implementation developed by Oracle (Oracle JDK is a build of OpenJDK under a commercial license). Projects are developed in OpenJDK (for the most part by Oracle employees because Oracle funds ~95% of OpenJDK's development, but there are some non-Oracle-led projects from time to time[1]) and are then approved by the JCP as an umbrella "Platform JSR" for a specific release (e.g. this is the one for the current version: https://openjdk.java.net/projects/jdk/12/spec/ https://openjdk.java.net/projects/jdk/12/spec/) [1]: E.g. the Shenandoah GC (https://wiki.openjdk.java.net/display/shenandoah https://wiki.openjdk.java.net/display/shenandoah) is led by Red Hat, TSAN (https://wiki.openjdk.java.net/display/tsan https://wiki.openjdk.java.net/display/tsan) is led by Google, and the s390 port (http://openjdk.java.net/projects/s390x-port/ http://openjdk.java.net/projects/s390x-port/) is led by SAP.
  - MaxBarraclough 8y ago
    Very neat. So it preserves the virtues of .Net's task-based concurrency, but is even less intrusive regarding the necessary code-changes to existing synchronous code. Does it impact things from the perspective of the JNI programmer? > OpenJDK is the name of the Java implementation developed by Oracle (Oracle JDK is a build of OpenJDK under a commercial license). Ah, of course. I'd missed that. > there are non-Oracle-led projects from time to time[1], and are then approved by the JCP as an umbrella "Platform JSR" for a specific release How do they handle copyright?
    - pron 8y ago
      > but is even less intrusive regarding the necessary code-changes to existing synchronous code. Yes. All existing blocking IO code will become automatically fiber-blocking rather than kernel-thread-blocking, except where there are OS issues (file IO; Go has the same problem). Fibers and threads may end up using the same API, as they're just two implementations of the same abstraction. > Does it impact things from the perspective of the JNI programmer? Fibers can freely call native code, either with JNI or with the upcoming Project Panama, which is set to replace it, but a fiber that tries to block inside a native call, i.e., when there is a native frame on the fiber's stack, will be "pinned" and block the underlying kernel thread. > How do they handle copyright? Both the contributors and Oracle own the copyright (i.e. both can do whatever they want with the code). This is common in large, company-run open source projects.
unscaled 8y ago
That's very nice, but saying it's strictly superior to async/await is a stretch. Fibers/stackful coroutines are a different approach with its own tradeoffs. On the plus side, fibers offer almost painless integration of synchronous code, while async/await suffer from the "colored functions" problem[1]. The price you pay for that, is the higher overhead of having to allocate stacks. If you don't support dynamic stacks which can be resized, you basically don't have a much better overhead than native threads. There are two solutions I'm aware of, both of them have been done by Go at different times: segmented stacks and re-aligning and copying the stack on resize. Both carry some memory overhead (unused stacks) and computational overhead (stack resizing). [1] http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
- pron 8y ago
  > Fibers/stackful coroutines are a different approach with its own tradeoffs. The only tradeoffs involved, as far as I'm aware, are effort of implementation. There are no runtime tradeoffs. > The price you pay for that, is the higher overhead of having to allocate stacks. You have to allocate memory to store the state of the continuation either way. Some languages can choose not to call the memory required for stackless continuations "stacks" but it's the same amount of memory. > Both carry some memory overhead (unused stacks) and computational overhead (stack resizing). Their "advantage" is that, because they're inconvenient, people try to keep those stacks shallow. Stackless continuations have the same issue. They use what amounts to segmented stacks. "Stackless" means that they're organized as separate frames.

by pron 8y ago

https://wiki.openjdk.java.net/display/loom/ https://wiki.openjdk.java.net/display/loom/ which is superior to async/await, if I may say so myself (I'm the project lead)

yawaramin 8y ago

> Fibers are user-mode lightweight threads that allow synchronous (blocking) code to be efficiently scheduled, so that it performs as well as asynchronous code Sounds a lot like Erlang BEAM processes.

pron 8y ago
Yep; or Go's goroutines. Except that the fibers are implemented and scheduled in the Java libraries; the VM only provides continuations.
- mycall 8y ago
  How does it compare to Windows fibers?

cozos 8y ago

I find this really interesting. Care to provide some comparisons?

MaxBarraclough 8y ago

Great article, thanks. Some perhaps-silly questions: 1. Is it possible to inspect the state of a 'parking' operation, the way you can in .Net with Task#Status? 2. So fibers run in 'carrier threads'. Is there a pool of carrier threads, or can any thread act as a carrier? I'm thinking of .Net's where this is configurable (ignoring that .Net 'contexts' aren't exactly threads), by means of Task#ContinueWith() and the Scheduler class. I take it from the following snippets that fibers can only run on the thread where they were created: starting or continuing a continuation mounts it and its stack on the current thread – conceptually concatenating the continuation's stack to the thread's – while yielding a continuation unmounts or dismounts it. And also: Parking (blocking) a fiber results in yielding its continuation, and unparking it results in the continuation being resubmitted to the scheduler. On a non-technical note, how do OpenJDK projects feed back into the Java spec and Oracle Java?

pron 8y ago
1. Yes. 2. Configurable. A fiber is assigned to a scheduler that is, at least currently, and Executor (so you can implement your own). > I take it from the following snippets that fibers can only run on the thread where they were created No. A fiber has no special relationship to the thread (or fiber) that created it, although now there can be a supervision hierarchy thanks to structured concurrency: https://wiki.openjdk.java.net/display/loom/Structured+Concurrency https://wiki.openjdk.java.net/display/loom/Structured+Concur... > OpenJDK projects feed back into the Java spec and Oracle Java? OpenJDK is the name of the Java implementation developed by Oracle (Oracle JDK is a build of OpenJDK under a commercial license). Projects are developed in OpenJDK (for the most part by Oracle employees because Oracle funds ~95% of OpenJDK's development, but there are some non-Oracle-led projects from time to time[1]) and are then approved by the JCP as an umbrella "Platform JSR" for a specific release (e.g. this is the one for the current version: https://openjdk.java.net/projects/jdk/12/spec/ https://openjdk.java.net/projects/jdk/12/spec/) [1]: E.g. the Shenandoah GC (https://wiki.openjdk.java.net/display/shenandoah https://wiki.openjdk.java.net/display/shenandoah) is led by Red Hat, TSAN (https://wiki.openjdk.java.net/display/tsan https://wiki.openjdk.java.net/display/tsan) is led by Google, and the s390 port (http://openjdk.java.net/projects/s390x-port/ http://openjdk.java.net/projects/s390x-port/) is led by SAP.
- MaxBarraclough 8y ago
  Very neat. So it preserves the virtues of .Net's task-based concurrency, but is even less intrusive regarding the necessary code-changes to existing synchronous code. Does it impact things from the perspective of the JNI programmer? > OpenJDK is the name of the Java implementation developed by Oracle (Oracle JDK is a build of OpenJDK under a commercial license). Ah, of course. I'd missed that. > there are non-Oracle-led projects from time to time[1], and are then approved by the JCP as an umbrella "Platform JSR" for a specific release How do they handle copyright?
  - pron 8y ago
    > but is even less intrusive regarding the necessary code-changes to existing synchronous code. Yes. All existing blocking IO code will become automatically fiber-blocking rather than kernel-thread-blocking, except where there are OS issues (file IO; Go has the same problem). Fibers and threads may end up using the same API, as they're just two implementations of the same abstraction. > Does it impact things from the perspective of the JNI programmer? Fibers can freely call native code, either with JNI or with the upcoming Project Panama, which is set to replace it, but a fiber that tries to block inside a native call, i.e., when there is a native frame on the fiber's stack, will be "pinned" and block the underlying kernel thread. > How do they handle copyright? Both the contributors and Oracle own the copyright (i.e. both can do whatever they want with the code). This is common in large, company-run open source projects.

unscaled 8y ago

That's very nice, but saying it's strictly superior to async/await is a stretch. Fibers/stackful coroutines are a different approach with its own tradeoffs. On the plus side, fibers offer almost painless integration of synchronous code, while async/await suffer from the "colored functions" problem[1]. The price you pay for that, is the higher overhead of having to allocate stacks. If you don't support dynamic stacks which can be resized, you basically don't have a much better overhead than native threads. There are two solutions I'm aware of, both of them have been done by Go at different times: segmented stacks and re-aligning and copying the stack on resize. Both carry some memory overhead (unused stacks) and computational overhead (stack resizing). [1] http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

pron 8y ago
> Fibers/stackful coroutines are a different approach with its own tradeoffs. The only tradeoffs involved, as far as I'm aware, are effort of implementation. There are no runtime tradeoffs. > The price you pay for that, is the higher overhead of having to allocate stacks. You have to allocate memory to store the state of the continuation either way. Some languages can choose not to call the memory required for stackless continuations "stacks" but it's the same amount of memory. > Both carry some memory overhead (unused stacks) and computational overhead (stack resizing). Their "advantage" is that, because they're inconvenient, people try to keep those stacks shallow. Stackless continuations have the same issue. They use what amounts to segmented stacks. "Stackless" means that they're organized as separate frames.