4 ms·

Can anyone fill me in on how this compares to Java's Project Loom approach where they have said a hard no to coloring functions. What are the advantages and dis

Can anyone fill me in on how this compares to Java's Project Loom approach where they have said a hard no to coloring functions. What are the advantages and disadvantages of async/await vs introducing a green thread like approach for problems? Is async/await more suitable for user interfaces?

_old_dude_ 6y ago
Implementing async/await is only a compiler change, so it can be implemented rather easily on top of any languages, the compiler transforms the code to a state machine. co-routine (Java Loom's one, Go one, Scheme one, etc) requires to be able to serialize and deserialize a part of the stack (move the stack on the the heap and vice versa), so it's hard/impossible to implement with non managed runtimes which like in C or objective C. In C, you can declare an address/pointer to an address on stack (using &), but with a co-routine mechanism, the addresses of parts of the stack are not constant. If you have a managed runtime, you rewrite those kind of pointers when you copy parts of the stack back and forth.
- gpderetta 6y ago
  With one stack per coroutine you do not have to move stack frames. It has different tradeoffs of course.
ynik 6y ago
async/await is more flexible in some sense. If you run the tasks on a thread pool, it's mostly equivalent to green threads. But if you run the tasks on a single thread, you get cooperative multi-tasking. You can access mutable shared state without using locks, as long as you don't use "await" while the shared state is in an inconsistent state. For user interfaces this is huge advantage: you can run all your code on the UI thread; but the UI stays responsive while awaiting tasks. Also, here's an interesting use of async/await: software hyperthreading: https://isocpp.org/blog/2019/09/cppcon-2018-nano-coroutines-to-the-rescue-using-coroutines-ts-of-course-g https://isocpp.org/blog/2019/09/cppcon-2018-nano-coroutines-...
- pron 6y ago
  Loom's virtual threads allow you to do the same with a pluggable scheduler.
  - jayd16 6y ago
    How does UI code work in Loom if you need, say, a single render thread to issue GL commands? Wouldn't you need a native thread (making Loom moot), or is there some other trick at play?
    - pjmlp 6y ago
      You can still pick and choose, native threads aren't going away, just like today you can make several tasks map to a single threaded.
      - jayd16 6y ago
        Alright. The trick is to not use Loom virtual threads. I will say Java's Loom is ruthlessly elegant in this way. But won't you run into issues where you don't want to call certain code from that UI thread? Isn't that "code coloring"?
        pjmlp 6y ago
        Code colouring usually means it won't even compile, like on C# async/await case. In your example, for Swing applications you should use invokeLater(Runnable r) anyway, and it doesn't matter what implements the interface.
    - pron 6y ago
      You would use a custom scheduler to schedule many virtual threads onto a particular native thread.
      - jayd16 6y ago
        I don't think this is enough. You still might interweave your draw commands, causing issues.
smasher164 6y ago
async/await is really just another formulation of linked stack frames, where control is explicitly yielded. At the end of the day, the thread stack state needs to be reified somehow, and all of these approaches are equivalent in power. The only difference is that now you have a type system that delineates between functions that can and cannot be shuffled between kernel threads. The benefits that Go (and potentially Loom) provide are with the scheduler. When Go code calls into other Go code, it's fast because preemption points can be inserted by the compiler. The goroutine is parked when it is blocked (on I/O or some foreign function), and in the slow path this logic is executed on a new kernel thread. Although the Go approach involves more overhead in the slow path, wrangling blocking code to work with the scheduler has cross-cutting implications for library design. I.e, I don't have to worry that a library I import that does file I/O will pin my goroutine to a blocked thread by using a blocking syscall.
- jayd16 6y ago
  Async/await provides a mechanism for explicit context switching between threads. This is useful when you might need to run code on specific native threads or other native tasks outside the runtime. It seems like it would be much harder or impossible in languages that work to hide these details. How do you go from implicit blocking to explicit native thread usage? At least Loom seems to be keeping native threads so Java code can simply fall back to that, I guess.
  - pjmlp 6y ago
    You can also use native threads in Go, by locking the current goroutine thread.
  - yxhuvud 6y ago
    One way to solve it is to introduce a concept like a nursery (a la structured concurrency) and when setting it up you instruct it to create a new thread that is only used for those particular tasks. This of course requires a scheduler that needs to handle hierarchical control of execution rather than having an unformed mass of tasks, but nurseries provide other benefits as well.
aardvark179 6y ago
In Loom we can make some trade offs around our knowledge of the Java stack and the standard library. 1. We know that no JVM frame contains a raw pointer to anywhere else in the stack. 2. We know which stack frames are JVM frames, and which are native frames. 3. We know that there are unlikely to be native frames in the portion of the stack between the point where we yield control and the point we want to yield to. 4. We can change the standard library to check if we are in our new lightweight thread or not and act appropriately. Knowing these we can avoid function coloring and push the complex management of green threads into the standard library, and reuse existing task scheduler code to manage these virtual threads, and we can work to make thread local variables etc work seamlessly with this new concurrency abstraction. This puts us in a very different design space. We can move a portion of the stack to the heap when a thread is unmounted, and we can change things about the GC and other internal systems to make them aware of this new thing that can be in the heap. This type of approach would be much harder in a language like swift that tends to coexist with C and other languages that use raw pointers or a non-moving GC, so I think the question is not which is the better approach but which is the better approach within your language ecosystem.
- didibus 6y ago
  If Loom ever comes out :p, at this point I am starting to wonder if this is a case of "the right thing" against "worse is better" and maybe we just will never see the light of Loom.
  - spullara 6y ago
    You can download loom and use it right now. I am pretty sure it will one day be released.
  - pron 6y ago
    Java is at a stage where it's clear it will continue to be a popular platform and language for decades to come. It can afford to do "the right thing" because the question it's facing is not how to attract more developers now, but how to avoid mistakes its numerous developers will pay for, and build solid foundations for many years to come. It's a common difference between young and established languages, and, naturally, Java made its own fair share of design mistakes when it was young. Of course, there are technical differences that make certain design choices easier or harder in different languages. As aardvark179 mentions above, Java doesn't have pointers into the stack, and intermediate FFI frames are extremely rare (also due to the platform's established and large ecosystem). (I'm the technical lead for OpenJDK's Project Loom)

_old_dude_ 6y ago

Implementing async/await is only a compiler change, so it can be implemented rather easily on top of any languages, the compiler transforms the code to a state machine. co-routine (Java Loom's one, Go one, Scheme one, etc) requires to be able to serialize and deserialize a part of the stack (move the stack on the the heap and vice versa), so it's hard/impossible to implement with non managed runtimes which like in C or objective C. In C, you can declare an address/pointer to an address on stack (using &), but with a co-routine mechanism, the addresses of parts of the stack are not constant. If you have a managed runtime, you rewrite those kind of pointers when you copy parts of the stack back and forth.

gpderetta 6y ago
With one stack per coroutine you do not have to move stack frames. It has different tradeoffs of course.

ynik 6y ago

async/await is more flexible in some sense. If you run the tasks on a thread pool, it's mostly equivalent to green threads. But if you run the tasks on a single thread, you get cooperative multi-tasking. You can access mutable shared state without using locks, as long as you don't use "await" while the shared state is in an inconsistent state. For user interfaces this is huge advantage: you can run all your code on the UI thread; but the UI stays responsive while awaiting tasks. Also, here's an interesting use of async/await: software hyperthreading: https://isocpp.org/blog/2019/09/cppcon-2018-nano-coroutines-to-the-rescue-using-coroutines-ts-of-course-g https://isocpp.org/blog/2019/09/cppcon-2018-nano-coroutines-...

pron 6y ago
Loom's virtual threads allow you to do the same with a pluggable scheduler.
- jayd16 6y ago
  How does UI code work in Loom if you need, say, a single render thread to issue GL commands? Wouldn't you need a native thread (making Loom moot), or is there some other trick at play?
  - pjmlp 6y ago
    You can still pick and choose, native threads aren't going away, just like today you can make several tasks map to a single threaded.
    - jayd16 6y ago
      Alright. The trick is to not use Loom virtual threads. I will say Java's Loom is ruthlessly elegant in this way. But won't you run into issues where you don't want to call certain code from that UI thread? Isn't that "code coloring"?
      - pjmlp 6y ago
        Code colouring usually means it won't even compile, like on C# async/await case. In your example, for Swing applications you should use invokeLater(Runnable r) anyway, and it doesn't matter what implements the interface.
  - pron 6y ago
    You would use a custom scheduler to schedule many virtual threads onto a particular native thread.
    - jayd16 6y ago
      I don't think this is enough. You still might interweave your draw commands, causing issues.

smasher164 6y ago

async/await is really just another formulation of linked stack frames, where control is explicitly yielded. At the end of the day, the thread stack state needs to be reified somehow, and all of these approaches are equivalent in power. The only difference is that now you have a type system that delineates between functions that can and cannot be shuffled between kernel threads. The benefits that Go (and potentially Loom) provide are with the scheduler. When Go code calls into other Go code, it's fast because preemption points can be inserted by the compiler. The goroutine is parked when it is blocked (on I/O or some foreign function), and in the slow path this logic is executed on a new kernel thread. Although the Go approach involves more overhead in the slow path, wrangling blocking code to work with the scheduler has cross-cutting implications for library design. I.e, I don't have to worry that a library I import that does file I/O will pin my goroutine to a blocked thread by using a blocking syscall.

jayd16 6y ago
Async/await provides a mechanism for explicit context switching between threads. This is useful when you might need to run code on specific native threads or other native tasks outside the runtime. It seems like it would be much harder or impossible in languages that work to hide these details. How do you go from implicit blocking to explicit native thread usage? At least Loom seems to be keeping native threads so Java code can simply fall back to that, I guess.
- pjmlp 6y ago
  You can also use native threads in Go, by locking the current goroutine thread.
- yxhuvud 6y ago
  One way to solve it is to introduce a concept like a nursery (a la structured concurrency) and when setting it up you instruct it to create a new thread that is only used for those particular tasks. This of course requires a scheduler that needs to handle hierarchical control of execution rather than having an unformed mass of tasks, but nurseries provide other benefits as well.

aardvark179 6y ago

In Loom we can make some trade offs around our knowledge of the Java stack and the standard library. 1. We know that no JVM frame contains a raw pointer to anywhere else in the stack. 2. We know which stack frames are JVM frames, and which are native frames. 3. We know that there are unlikely to be native frames in the portion of the stack between the point where we yield control and the point we want to yield to. 4. We can change the standard library to check if we are in our new lightweight thread or not and act appropriately. Knowing these we can avoid function coloring and push the complex management of green threads into the standard library, and reuse existing task scheduler code to manage these virtual threads, and we can work to make thread local variables etc work seamlessly with this new concurrency abstraction. This puts us in a very different design space. We can move a portion of the stack to the heap when a thread is unmounted, and we can change things about the GC and other internal systems to make them aware of this new thing that can be in the heap. This type of approach would be much harder in a language like swift that tends to coexist with C and other languages that use raw pointers or a non-moving GC, so I think the question is not which is the better approach but which is the better approach within your language ecosystem.

didibus 6y ago
If Loom ever comes out :p, at this point I am starting to wonder if this is a case of "the right thing" against "worse is better" and maybe we just will never see the light of Loom.
- spullara 6y ago
  You can download loom and use it right now. I am pretty sure it will one day be released.
- pron 6y ago
  Java is at a stage where it's clear it will continue to be a popular platform and language for decades to come. It can afford to do "the right thing" because the question it's facing is not how to attract more developers now, but how to avoid mistakes its numerous developers will pay for, and build solid foundations for many years to come. It's a common difference between young and established languages, and, naturally, Java made its own fair share of design mistakes when it was young. Of course, there are technical differences that make certain design choices easier or harder in different languages. As aardvark179 mentions above, Java doesn't have pointers into the stack, and intermediate FFI frames are extremely rare (also due to the platform's established and large ecosystem). (I'm the technical lead for OpenJDK's Project Loom)