3 ms·

What will be the implications of this? e.g. Can we now handle more req/sec on I/O blocking services, because more requests can be serviced by VTs and they will

by rockyj 2y ago

What will be the implications of this? e.g. Can we now handle more req/sec on I/O blocking services, because more requests can be serviced by VTs and they will not be blocked waiting for IO, so kinda like Node.js async model (for free) but with multiple threads?

samus 2y ago
That was always possible and the whole point of virtual threads. This concerns reliability. So far there was this annoying papercut of virtual threads not freeing up their carrier thread when they were waiting to enter a `synchronized` lock. That could easily lead to reduced throughput or even deadlocks when all carrier threads got pinned.
- rockyj 2y ago
  Yeah, I mean now we can start using VTs on any system / lib without being worried of pinning. Isn't this a "huge" deal? Why is the community not shouting from the rooftops about this? Theoretically it means, Java has now bettered Node.js "async / await" approach and that too without the two colored function approach. One process can now spawn thousands of threads to service IO and none of those threads are blocking / waiting (and with this release there is no gotcha / pitfall remaining). Not mention all the Netty / reactive libraries have no use now (not that I am complaining).
  - samus 2y ago
    Indeed, the relief is great. However, there are relatively few users of virtual threads yet. Even fewer are keeping up with the releases. Those using it in production already managed to work around the issues or have given up on it. We will hear more when Java 25 is released (which will be an Oracle LTS version) or if a backport to LTS 21 happens.
  - munksbeer 2y ago
    > Not mention all the Netty / reactive libraries have no use now (not that I am complaining). Netty uses an eventloop/async paradigm. The benefit of that style is you do not need any locking (within the same eventloop). How does virtual threads make that of no use?
    - rockyj 2y ago
      No need for complex async / event loop stuff. VTs can be spawned by millions and they will not block the thread (/CPU) while doing IO, in this (win-win) scenario there is no value in doing complex (and 2 colored) async programming.
      - munksbeer 2y ago
        You didn't answer the question though. When I use a single threaded event loop with async style, I don't need to use any locks. It isn't about efficiency, it is about low complexity because I don't need to reason about shared state. Is it good practice or not to use locking semantics if you use virtual threads?
        samus 2y ago
        It is totally fine to use locking with virtual threads. Of course you don't need it if you don't have to restrict access to shared resources in the first place (for example a connection pool or a datastructure with internal invariants that have to be maintained) or if lockless alternatives are available.
hmottestad 2y ago
You can now safely use virtual threads to run code that uses "synchronized".
skerit 2y ago
As someone coming from Node.js: virtual threads are amazing. Async behaviour without the async/await headaches.
ludovicianul 2y ago
My first experience with virtual threads was way less memory used.
- znpy 2y ago
  > My first experience with virtual threads was way less memory used. understandable. Normal java threads have underlying OS threads, which have their own stack and memory overhead. virtual threads are much lighter in this sense.

by rockyj 2y ago

samus 2y ago

That was always possible and the whole point of virtual threads. This concerns reliability. So far there was this annoying papercut of virtual threads not freeing up their carrier thread when they were waiting to enter a `synchronized` lock. That could easily lead to reduced throughput or even deadlocks when all carrier threads got pinned.

rockyj 2y ago
Yeah, I mean now we can start using VTs on any system / lib without being worried of pinning. Isn't this a "huge" deal? Why is the community not shouting from the rooftops about this? Theoretically it means, Java has now bettered Node.js "async / await" approach and that too without the two colored function approach. One process can now spawn thousands of threads to service IO and none of those threads are blocking / waiting (and with this release there is no gotcha / pitfall remaining). Not mention all the Netty / reactive libraries have no use now (not that I am complaining).
- samus 2y ago
  Indeed, the relief is great. However, there are relatively few users of virtual threads yet. Even fewer are keeping up with the releases. Those using it in production already managed to work around the issues or have given up on it. We will hear more when Java 25 is released (which will be an Oracle LTS version) or if a backport to LTS 21 happens.
- munksbeer 2y ago
  > Not mention all the Netty / reactive libraries have no use now (not that I am complaining). Netty uses an eventloop/async paradigm. The benefit of that style is you do not need any locking (within the same eventloop). How does virtual threads make that of no use?
  - rockyj 2y ago
    No need for complex async / event loop stuff. VTs can be spawned by millions and they will not block the thread (/CPU) while doing IO, in this (win-win) scenario there is no value in doing complex (and 2 colored) async programming.
    - munksbeer 2y ago
      You didn't answer the question though. When I use a single threaded event loop with async style, I don't need to use any locks. It isn't about efficiency, it is about low complexity because I don't need to reason about shared state. Is it good practice or not to use locking semantics if you use virtual threads?
      - samus 2y ago
        It is totally fine to use locking with virtual threads. Of course you don't need it if you don't have to restrict access to shared resources in the first place (for example a connection pool or a datastructure with internal invariants that have to be maintained) or if lockless alternatives are available.

hmottestad 2y ago

You can now safely use virtual threads to run code that uses "synchronized".

skerit 2y ago

As someone coming from Node.js: virtual threads are amazing. Async behaviour without the async/await headaches.

ludovicianul 2y ago

My first experience with virtual threads was way less memory used.

znpy 2y ago
> My first experience with virtual threads was way less memory used. understandable. Normal java threads have underlying OS threads, which have their own stack and memory overhead. virtual threads are much lighter in this sense.