9 ms·

I think a lot of people are missing the point. Go look at the sourcecode. Look at how simple it is - anyone who has created a thread with java knows what's hap

I think a lot of people are missing the point. Go look at the sourcecode. Look at how simple it is - anyone who has created a thread with java knows what's happening. With only minor tweaks, this means your pre-existing code can take advantage of this with, basically, no effort. And it retains all the debuggability of traditional java thread (I.e: a stack trace that makes sense!) If you've spent any time at all dealing with the horrors of c# async/await (Why am I here? Oh, no idea) and it's doubling of your APIs to support function colouring - or, you've fought with the complexities of reactive solutions in the Java space -- often, frankly, in the name of "scalability" that will never be practically required -- this is a big deal. You no longer have to worry about any of that.

bullen 4y ago
Agreed it's simpler, but using NIO with one OS thread per core also has it's benefits. The context switch (how ever small) will cause latency when this solution is at saturation. I think they should write four tests: fiber, NIO and each with userspace networking (no kernel copying network memory) and compare them. Why Oracle is stalling removing the kernel for Java networking is surprising to me, they allready have a VM.
- pron 4y ago
  https://github.com/ebarlas/project-loom-comparison https://github.com/ebarlas/project-loom-comparison
  - vlovich123 4y ago
    Shouldn’t you be able to send authorization and authentication requests in parallel in the async and virtual threads cases?
    - threeseed 4y ago
      It is just an example so they could do anything. But in the real world it is common to need information from the authorization stage to use in the authentication stage. For example you may have a user login with an email address/password which you then pass to an LDAP server in order to get a userId. This userId is then used in a database to determine with objects/groups they have access to.
      - vlovich123 4y ago
        A lower latency design would be for the authorization service to be able to work with either. That way those requests could be done in parallel to reduce latency.
  - bullen 4y ago
    Thx, I'm missing bandwidth and latency in those graphs.
- blibble 4y ago
  there's still a context switch with NIO, you're just doing it manually
  - bullen 4y ago
    The context switches in NIO is between fewer threads, you just need one per core. Memory contention is also playing into this. The benchmark they made is asking the question in a way that it leans into the answer they need, just like 99% of all human activity it's biased.
    - blibble 4y ago
      you're missing the point and taking "context switch" literally with NIO you are still managing the stack, just yourself instead of letting the operating system do it for you it is still a "context switch", just done in your code instead of the OS and that's not free (and likely more expensive than saving and restoring a set of registers)
pjmlp 4y ago
Or inserting the occasional Task.Run() calls, as means to avoiding changing the whole call stack up to Main().
- gavinray 4y ago
  This hasn't been that much of a problem, IME If you decide somewhere deep in your program you want to use async operations, most languages allow you to keep the invoking function/closure synchronous and return some kind of Promise/Future-like value
  - pjmlp 4y ago
    Which is exactly the workaround with Task.Run(), being able to integrate a library written with async/await in codebases older than the feature, where no one is paying for a full rewrite.
SemanticStrengh 4y ago
Except Kotlin coroutines already works, can be very easily integrated in existing java codebases and are much superior than loom (structured concurrency, flow, etc)
- richdougherty 4y ago
  Kotlin coroutines are amazing. They're built on very clever tech that converts fairly normal source code into a state machine when compiled. This has huge benefits and allows the programmer to break their code up without the hassle of explicitly programming callbacks, etc. https://kotlinlang.org/spec/asynchronous-programming-with-coroutines.html https://kotlinlang.org/spec/asynchronous-programming-with-co... However... an unavoidable fact is that converted code works differently to other code. The programmer needs to know the difference. Normal and converted code compose together differently. The Kotlin compiler and type system helps keep track, but it can't paper over everything. Having lightweight thread and continuations support directly in the VM makes things very much simpler for programmers (and compiler writers!) since the VM can handle the details of suspending/resuming and code composes together effortlessly, even without compiler support, so it works across languages and codebases. I don't want to be critical about Kotlin. It's amazing what it achieves and I'm a big fan of this stuff. Here are some notes I wrote on something similar, Scala's experiments with compile-time delimited continuations: https://rd.nz/2009/02/delimited-continuations-in-scala_24.html https://rd.nz/2009/02/delimited-continuations-in-scala_24.ht... I think this is a general principle about compiler features vs runtime features. Having things in the runtime makes life a lot easier for everyone, at the cost of runtime complexity, of course. Another one I'd like to see is native support for tail calls in Java. Kotlin, Scala, etc have to do compile-time tricks to get basic tail call support, but it doesn't work across functions well. Scala and Kotlin both ask the programmer to add annotations where tail calls are needed, since the code gen so often fails. https://kotlinlang.org/docs/functions.html#tail-recursive-functions https://kotlinlang.org/docs/functions.html#tail-recursive-fu... https://www.scala-lang.org/api/3.x/scala/annotation/tailrec.html https://www.scala-lang.org/api/3.x/scala/annotation/tailrec.... https://rd.nz/2009/04/tail-calls-tailrec-and-trampolines.html https://rd.nz/2009/04/tail-calls-tailrec-and-trampolines.htm... As a side note, I can see that tail calls are planned for Project Loom too, but I haven't heard if that's implemented yet. Does anyone know the status? "Project Loom is to intended to explore, incubate and deliver Java VM features and APIs built on top of them for the purpose of supporting easy-to-use, high-throughput lightweight concurrency and new programming models on the Java platform. This is accomplished by the addition of the following constructs: * Virtual threads * Delimited continuations * Tail-call elimination" https://wiki.openjdk.java.net/display/loom/Main https://wiki.openjdk.java.net/display/loom/Main

bullen 4y ago

Agreed it's simpler, but using NIO with one OS thread per core also has it's benefits. The context switch (how ever small) will cause latency when this solution is at saturation. I think they should write four tests: fiber, NIO and each with userspace networking (no kernel copying network memory) and compare them. Why Oracle is stalling removing the kernel for Java networking is surprising to me, they allready have a VM.

pron 4y ago
https://github.com/ebarlas/project-loom-comparison https://github.com/ebarlas/project-loom-comparison
- vlovich123 4y ago
  Shouldn’t you be able to send authorization and authentication requests in parallel in the async and virtual threads cases?
  - threeseed 4y ago
    It is just an example so they could do anything. But in the real world it is common to need information from the authorization stage to use in the authentication stage. For example you may have a user login with an email address/password which you then pass to an LDAP server in order to get a userId. This userId is then used in a database to determine with objects/groups they have access to.
    - vlovich123 4y ago
      A lower latency design would be for the authorization service to be able to work with either. That way those requests could be done in parallel to reduce latency.
- bullen 4y ago
  Thx, I'm missing bandwidth and latency in those graphs.
blibble 4y ago
there's still a context switch with NIO, you're just doing it manually
- bullen 4y ago
  The context switches in NIO is between fewer threads, you just need one per core. Memory contention is also playing into this. The benchmark they made is asking the question in a way that it leans into the answer they need, just like 99% of all human activity it's biased.
  - blibble 4y ago
    you're missing the point and taking "context switch" literally with NIO you are still managing the stack, just yourself instead of letting the operating system do it for you it is still a "context switch", just done in your code instead of the OS and that's not free (and likely more expensive than saving and restoring a set of registers)

pjmlp 4y ago

Or inserting the occasional Task.Run() calls, as means to avoiding changing the whole call stack up to Main().

gavinray 4y ago
This hasn't been that much of a problem, IME If you decide somewhere deep in your program you want to use async operations, most languages allow you to keep the invoking function/closure synchronous and return some kind of Promise/Future-like value
- pjmlp 4y ago
  Which is exactly the workaround with Task.Run(), being able to integrate a library written with async/await in codebases older than the feature, where no one is paying for a full rewrite.

SemanticStrengh 4y ago

Except Kotlin coroutines already works, can be very easily integrated in existing java codebases and are much superior than loom (structured concurrency, flow, etc)

richdougherty 4y ago
Kotlin coroutines are amazing. They're built on very clever tech that converts fairly normal source code into a state machine when compiled. This has huge benefits and allows the programmer to break their code up without the hassle of explicitly programming callbacks, etc. https://kotlinlang.org/spec/asynchronous-programming-with-coroutines.html https://kotlinlang.org/spec/asynchronous-programming-with-co... However... an unavoidable fact is that converted code works differently to other code. The programmer needs to know the difference. Normal and converted code compose together differently. The Kotlin compiler and type system helps keep track, but it can't paper over everything. Having lightweight thread and continuations support directly in the VM makes things very much simpler for programmers (and compiler writers!) since the VM can handle the details of suspending/resuming and code composes together effortlessly, even without compiler support, so it works across languages and codebases. I don't want to be critical about Kotlin. It's amazing what it achieves and I'm a big fan of this stuff. Here are some notes I wrote on something similar, Scala's experiments with compile-time delimited continuations: https://rd.nz/2009/02/delimited-continuations-in-scala_24.html https://rd.nz/2009/02/delimited-continuations-in-scala_24.ht... I think this is a general principle about compiler features vs runtime features. Having things in the runtime makes life a lot easier for everyone, at the cost of runtime complexity, of course. Another one I'd like to see is native support for tail calls in Java. Kotlin, Scala, etc have to do compile-time tricks to get basic tail call support, but it doesn't work across functions well. Scala and Kotlin both ask the programmer to add annotations where tail calls are needed, since the code gen so often fails. https://kotlinlang.org/docs/functions.html#tail-recursive-functions https://kotlinlang.org/docs/functions.html#tail-recursive-fu... https://www.scala-lang.org/api/3.x/scala/annotation/tailrec.html https://www.scala-lang.org/api/3.x/scala/annotation/tailrec.... https://rd.nz/2009/04/tail-calls-tailrec-and-trampolines.html https://rd.nz/2009/04/tail-calls-tailrec-and-trampolines.htm... As a side note, I can see that tail calls are planned for Project Loom too, but I haven't heard if that's implemented yet. Does anyone know the status? "Project Loom is to intended to explore, incubate and deliver Java VM features and APIs built on top of them for the purpose of supporting easy-to-use, high-throughput lightweight concurrency and new programming models on the Java platform. This is accomplished by the addition of the following constructs: * Virtual threads * Delimited continuations * Tail-call elimination" https://wiki.openjdk.java.net/display/loom/Main https://wiki.openjdk.java.net/display/loom/Main