Project loom: what makes the performance better when using virtual threads?

Question

To give some context here, I have been following project loom for some time now. I have read the state of loom. I have done asynchronous programming.

Asynchronous programming (provided by java nio) returns the thread to the thread pool when the task waits and it goes to great lengths to not block threads. And this gives a large performance gain, we can now handle many more request as they are not directly bound by the number of OS threads. But what we lose here, is the context. The same task is now NOT associated with just one thread. All the context is lost once we dissociate tasks from threads. Exception traces do not provide very useful information and debugging is difficult.

In comes project loom with virtual threads that become the single unit of concurrency. And now you can perform a single task on a single virtual thread.

It's all fine until now, but the article goes on to state, with project loom:

A simple, synchronous web server will be able to handle many more requests without requiring more hardware.

I don't understand how we get performance benefits with project loom over asynchronous APIs? The asynchrounous APIs make sure to not keep any thread idle. So, what does project loom do to make it more efficient and performant that asynchronous APIs?

EDIT

Let me re-phrase the question. Let's say we have an http server that takes in requests and does some crud operations with a backing persistent database. Say, this http server handles a lot of requests - 100K RPM. Two ways of implementing this:

1. The HTTP server has a dedicated pool of threads. When a request comes in, a thread carries the task up until it reaches the DB, wherein the task has to wait for the response from DB. At this point, the thread is returned to the thread pool and goes on to do the other tasks. When DB responds, it is again handled by some thread from the thread pool and it returns an HTTP response.
2. The HTTP server just spawns virtual threads for every request. If there is an IO, the virtual thread just waits for the task to complete. And then returns the HTTP Response. Basically, there is no pooling business going on for the virtual threads.

Given that the hardware and the throughput remain the same, would any one solution fare better than the other in terms of response times or handling more throughput?

My guess is that there would not be any difference w.r.t performance.

Answer 1

We don't get benefit over asynchronous API. What we potentially will get is performance similar to asynchronous, but with synchronous code.