project-loom-c5m VS project-loom-comparison

It is not. Blocking IO (with some exceptions mentioned in the JEP) will automatically be translated by the runtime into non-blocking IO when it occurs on virtual threads, and no OS threads will be blocked. You can have a million threads blocking on a million sockets (obviously without creating a million OS threads): https://github.com/ebarlas/project-loom-c5m

You can't do that with thread pools. You could achieve that scalability with async code, but then observability tools will not be able to track the IO operations and who initiated them, but with virtual threads you'll see exactly what business operation is doing what IO and why.

That might change in JDK 21 (with virtual threads). See this https://github.com/ebarlas/project-loom-c5m . It achieve 5 million persistent connections (again depends on the server capacity and kernal tuning) using normal simple blocking code (https://github.com/ebarlas/project-loom-c5m/blob/main/src/main/java/loomtest/EchoServer.java) . It's a far better better programming model compared to JS async/await.

Nothing to do with the project, but I read through it, so...

1. It's built natively on Jetty - very tight integration, not just some libs running in a Jetty container.

2. Web is inherently Request/Response - all of this can be handled with dramatically less resource requirements using Virtual Threads. Web is sort of the absolutely-best-use-case for Virtual Threads where as a Game Engine would be the opposite of that (one critical rendering thread and MAYBE a few extra long-lived threads for processing physics, audio, etc.)

3. I haven't tried debugging a Loom project but it's been in incubation for just under 100 years so I have to imagine this has been figured out.

4. About twice the throughput and 1/2 the latency of full OS threads - https://github.com/ebarlas/project-loom-comparison

An interesting benchmark using ApacheBench on GitHub by Elliot Barlas