[groestl]

It's combining the benefits from async models (state machines separated from os threads, thus more optimal for I/O bound workload), with the benefits from proper threading models (namely the simpler human interface).

Memory utilization & performance is going to be similar to the async callback mess.

[hashmash]

Why is an async model better than using OS threads for an I/O bound workload? The OS is doing async stuff internally and shielding the complexity with threads. With virtual threads this work has shifted to the JVM. Can the JVM do threads better than the OS?

[mrsilencedogood]

"Why is an async model better than using OS threads for an I/O bound workload?"

Because evented/callback-driven code is a nightmare to reason about and breaks lots of very basic tools, like the humble stack trace.

Another big thing for me is resource management - try/finally don't work across callback boundaries, but do work within a virtual thread. I recently ported a netty-based evented system to virtual threads and a very long-standing issue - resource leakage - turned into one very nice try/finally block.

[zokier]

> Can the JVM do threads better than the OS?

Yes. The JVM has far more opportunities for optimizing threads because it doesn't need to uphold 50 years of accumulated invariants and compatibility that current OSes do, and JVM has more visibilty on the application internals.

[adgjlsfhk1]

it can do a much better job because there isn't a security boundary. OS thread scheduling requires sys calls and invalidate a bunch of cache to prevent timing leaks