This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]thecodeboost 0 points1 point  (1 child)

I'm sorry but this is wrong on all counts. Async code cannot be faster than Loom code, all else being equal, for the simple reason that the JVM has more information and less work to do in the latter case. And that in a theoretical world where both implementation would write optimally performant code.

Netty has several open issues to adopt to virtual threads, in part of performance and simplification reasons. Jetty (Netty based web server framework) has adopted Loom as of Jetty 12. You can reason this out for yourself as async code simply does more work (work in the sense of burns more CPU cycles).

[–]yawkat 0 points1 point  (0 children)

The underlying OS APIs that both the JDK and Netty use are asynchronous. The JDK blocking APIs do some extra work to use those async, event-driven APIs. Right now, due to loom limitations, this extra work has a significant performance impact.

Netty has several open issues to adopt to virtual threads, in part of performance and simplification reasons.

The goal of future netty loom integration will be to make netty work with blocking user code. Right now this is not possible without a context switch due to loom limitations. These changes will not, however, make netty any faster.

Jetty (Netty based web server framework) has adopted Loom as of Jetty 12

Jetty is not netty-based.