Vert.x Event-Loop vs Virtual Threads: Jactl Suspend/Resume Benchmark

[u/jaccomoc]

https://jactl.io/blog/2026/09/02/jactl-virtual-threads-benchmark

The article benchmarks Jactl script execution with differing number of blocking operations comparing throughput with Jactl built-in suspend/resume on Vert.x Event-Loops and throughput with Jactl on Virtual Threads. The benchmarks are run on both Java 21 and Java 25 with some surprising (to me at least) results.

[u/s0ftware-dev]

TLDR virtual threads are better. 

[u/neopointer → u/s0ftware-dev]

And don't use reactor, vertx or anything similarly hard to debug and maintain.

[u/jaccomoc → u/s0ftware-dev]

But only on Java 25 and not by as much as I thought they would be.

I was frankly surprised at the difference between Java 21 and Java 25.

[u/Neful34 → u/jaccomoc]

Nah if you follow a bit the java youtube channel they explained a lot about the optimizations and the issues they had with virtual threads in java 21, and the optimization they did in java 25. I also recall a recent talk from netflix discussing about it too

[u/jaccomoc → u/Neful34]

I know that they fixed the OS thread pinning issues and that there are always some performance improvements but the the improvement for scripts with multiple blocking operations was a lot more significant than I expected. Or maybe what I should say is that the performance on Java 21 when a script does multiple blocking operations with virtual threads was a lot worse than I expected.

[u/Joram2 → u/jaccomoc]

Even at similar speeds, the Vert.x event loop has a much higher complexity cost. I've used vert.x for years, it's great, a lot of the vert.x platform has value with virtual threads, but the future for most use cases is clearly virtual threads.

[u/jaccomoc → u/Joram2]

I agree completely. It wins alone just by removing all the async code handling we used to have to do.

[u/BarkiestDog → u/jaccomoc]

Both were significantly better in Java 25, but virtual thread was a lot better!

[u/yawkat]

Three issues with this:

• AFAICS this is a closed model load, which is a batch processing workload. In a typical vertx application you have an open model load instead. See this article: https://www.scylladb.com/2021/04/22/on-coordinated-omission/
• Because this is JMH, it does not mirror "batchy" behavior of network interfaces, which is the typical use case for vertx.
• When tasks block, they are typically waiting for IO work, not sleeping. This has implications for scheduling.

[u/jaccomoc → u/yawkat]

Thanks for the feedback. I agree that the test is not ideal but I am not sure about you saying that the load is a closed model load. The test queues (for Vert.x) all requests or creates virtual threads for all requests and then waits for them all to finish. Isn't that an open model load?

[u/pron98]

The improvement in JDK 25 wasn't in virtual threads, it was in Thread.sleep ;) (although between 22 and 25 there were also improvements to IO on virtual threads). Timed and untimed parks use different mechanisms, and we can't draw conclusions from one to the other; it was the timed park specifically that wasn't very efficient in JDK 21, but it's also used mostly in benchmarks and tests. Different kinds of IO also go through different mechanisms, and we can't extrapolate from one to another.

This demonstrates the danger in extrapolating and drawing conclusions from benchmarks: they measure themselves, and to extrapolate anything you need to know exactly which variables matter and when. Between concurrent algorithms that behave completely differently under low and high contention, code with slow and fast paths, optimising compilers that depend on the call graph, branch prediction, a cache hierarchy, and memory management that depends on the global behaviour of the program and on how long it's running (malloc/free is actually much more sensitive to this than Java's moving GCs [1]), it's virtually impossible to draw any conclusions from any benchmark, in any language, unless you know exactly how the mechanism is implemented, how the compiler is implemented, and how memory management is implemented.

Also, benchmark code often behaves so differently from real code, that the code takes different paths, and some improvements matter only to real programs and not to most benchmarks, and some matter almost exclusively to benchmarks. We usually try to focus on real programs, but sometimes we say, you know what, let's make the benchmarks look better, too...

[1]: I've seen benchmarks where C++ outperforms Java only because there is nothing else in the program besides the benchmark code, which happens to only hit the malloc/free fast path and never trigger the slow path; if the program also had other code, the results would have been reversed.

[u/jaccomoc → u/pron98]

That's good to know, thanks. To be honest, I did have doubts about using sleep() as a proxy for other blocking operations but it was easier to do that than to include a real web service call or equivalent. And, running a web server would mean that measuring max throughput on a single machine would be impacted by the performance of the web server as well (unless it was on a separate server in which case the test would no longer be self-contained).

I have updated the article with a Postscript section with this additional information.

[u/New-Departure-5969]

benchmarks are fun but in prod the event loop usually dies from accidental blocking (jdbc, sync stuff), not from the loop itself. we had a vert.x api around 12k tps / ~100ms p99.99 and the real win was ditching blocking jdbc for the vert.x pool. virtual threads help, but saturated pools still wreck p99.

[u/Known-Volume1509]

It doesn't say what Vert.x version is this? Vert.x 5 supports virtual thread verticles. Curious if you run your tests against that, even though it's no longer event-loop.

Also, isn't this horribly costly?

For the Jactl Vert.x tests, the sleep() call will create a Continuation by throwing an exception and capturing the execution state so that it can be resumed once the sleep completes. When the script suspends, the script returns and the event-loop thread is then able to process the next event in its queue.

[u/jaccomoc → u/Known-Volume1509]

The article lists the versions of everything. It shows Vert.x as version 4.5.33. I didn't benchmark against 5.x because I am still retaining Java 8 compatibility for the moment and Vert.x 5.x needs Java 11 as a minimum.

Throwing an exception is not expensive if you don't fill in the stack trace (and the benchmarks support this). See Jactl Continuations and Virtual Threads in Java 8 for a description of how all this works.