Runtime: Question about async with fibers (like java project Loom)

[valeriob]

Hi,
i've looked briefly at Java project Loom : https://www.youtube.com/watch?v=J31o0ZMQEnI
If i understand correctly the project is exploring the application of using fiber to schedule computations instead of the threadpool, this would make all code automatically "async" optimized, because no thread would be stuck waiting, but just a fiber.
Is this concept been investigated on clr as an alternative to TPL/async-await ?

[svick]

What would be the advantage of having two different ways of achieving the same goal?

[valeriob]

that fibers require no code change, returning task is viral

[svick]

@valeriob Right, that's the advantage of fibers, but that's not what I'm asking.

At this point, pretty much all libraries and presumably most applications that would benefit from this have already been converted to async-await. How does it make sense to introduce fibers at this point, especially since it would probably mean we would be stuck with having to deal with both kinds of dealing with asynchony (or all 4, if you count APM and EAP)?

[jkotas]

Is this concept been investigated on clr as an alternative to TPL/async-await ?

Yes, this concept has been investigated in depth when the Task APIs were introduced originally and discussed number of times since then.

Some of the challenges with fibers are:

• OS fibers (as they exist on Windows OS) have regular stacks that makes them too expensive.
• The performant implementations need to use special stacks (segmented stacks or stack copying).
• The special stacks need to be switched to regular stack for interop. The Loom talk touches on it towards the end. This switching is not free. It basically just moves costs around. YMMV. Here is write up on Rust experience with segmented stack that has details about the trade-offs: https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html.

It would be certainly nice in some cases to not worry about whether to make method async or not. For better or worse, .NET choose to have explicit annotations for what needs to be async.

Our current thinking is keep improving efficiency async methods . For example, one async method cannot really be inlined into another async method today by the JIT. It is something we would like to fix.

[valeriob]

Thanks @jkotas ! I was asking exactly about the trade of that was chosen, if fibers where investigated/prototyped 😄
Do you know of any language that has implemented it ? I though that those where solved problem, at least for the BEAM vm.

[jkotas]

Do you know of any language that has implemented it?

golang

[valeriob]

golang

Thanks i did know that, that explains a lot 😄

[HaloFour]

Java is also looking to adopt green threads with OpenJDK Loom. They make the argument that async-specific APIs and language features are workarounds for the real problem, that blocking threads is bad because threads are so expensive. Async APIs and language features are also "viral" and create the situation of "function colors" where your sync code and async code should never mix, which is true in C#.

I'm not going to make the argument that the CLR or C# should change tact here, but I think it's very interesting to see what Java is doing in this space. The early access builds show a lot of promise.