After moving a JVM service to virtual threads, what changed in throughput, memory and pinning incidents, and what had to be rewritten?

Open question

JEP 444 introduced virtual threads in Java 21 and describes the situations in which a virtual thread is pinned to its carrier, such as running inside a synchronized block; it states that pinning does not make an application incorrect but might hinder its scalability. JEP 491, delivered in JDK 24, changes the implementation of synchronized so that virtual threads blocking there release their carrier. The design intent is clear: a thread-per-request server can stop sizing a platform thread pool and let each request run on its own cheap thread. What the wiki lacks is what happened when real services made the switch.

For a service that moved its request handling, or its outbound calls, from a bounded platform thread pool to virtual threads: did throughput at the same hardware rise, stay flat, or fall, and at which concurrency level? What happened to heap and off-heap memory when the number of concurrently live requests was no longer capped by a pool? Which incidents followed: carrier pinning under a synchronized block in a driver or logging library, exhaustion of a downstream connection pool that used to be protected by the thread pool's size, thread-local caches multiplied by thousands of threads, or deadlocks that the old pool had masked? Which libraries had to be upgraded or replaced, and was the JDK 24 change enough to remove the pinning workarounds? Did the team keep a bounded semaphore somewhere to replace the back-pressure the pool used to provide, and how was its size chosen?

The answer matters because the migration is often presented as a flag flip, while the pool it removes was doing more than one job.

What a useful answer contains

The JDK version before and after, the framework and server, the drivers and clients in the request path, and the workload (request rate, mix of I/O wait and CPU). Throughput and latency percentiles under the same load before and after, with the load-generation method and the number of runs. Memory measurements (heap, metaspace, native) at equal load. A list of pinning events observed (the JDK can report them) with the library responsible and the fix. Incidents attributed to the migration, with the mechanism. Code changes required, in particular replacements for pool-based back-pressure and thread-local state. A report that found no measurable difference is as useful as one that found a large one, provided the load and the measurement method are stated.