Add Helidon SE 4.4 (Java — Níma virtual threads web server)#235
Open
BennyFranciscus wants to merge 2 commits intoMDA2AV:mainfrom
Open
Add Helidon SE 4.4 (Java — Níma virtual threads web server)#235BennyFranciscus wants to merge 2 commits intoMDA2AV:mainfrom
BennyFranciscus wants to merge 2 commits intoMDA2AV:mainfrom
Conversation
Helidon SE 4.4.0 — Oracle's cloud-native Java framework with its own Níma WebServer built on Java 21 virtual threads. Unlike other JVM entries (Spring/Tomcat, Quarkus/Netty, Vert.x/Netty, Ktor/Netty), Helidon uses a custom server with thread-per-request on virtual threads. Endpoints: baseline, pipelined, limited-conn, json, upload, compression, noisy, mixed, async-db (HikariCP + PostgreSQL), static files. Uses Jackson for JSON, SQLite JDBC (thread-local, read-only, mmap), HikariCP for PostgreSQL connection pooling. JVM: Eclipse Temurin 25, ZGC, UseNUMA, AlwaysPreTouch.
BennyFranciscus
requested review from
Kaliumhexacyanoferrat and
MDA2AV
as code owners
jerrythetruckdriver
left a comment
jerrythetruckdriver
left a comment
There was a problem hiding this comment.
-XX:-StackTraceInThrowable disables stack trace generation on all exceptions. No production deployment guide recommends this — it trades debuggability for speed and falls under "experimental or unstable options that trade safety for speed" (implementation rules).
Drop that flag. The other JVM flags (ZGC, UseNUMA, AlwaysPreTouch) are standard production tuning and fine to keep.
Drops the flag per review feedback — disabling stack traces trades debuggability for speed, which violates implementation rules on experimental/unsafe options.
Collaborator
Author
|
Good call — dropped |
Owner
|
/benchmark |
|
🚀 Benchmark run triggered for |
Benchmark ResultsFramework: Full log |
Collaborator
Author
|
Benchmark results look solid! 🎉 Highlights:
Upload at ~750 req/s is on the lower end but not unusual for JVM frameworks handling 20MB bodies. Memory peaks at 18.6GiB during upload which is reasonable. Async-db at 9.6-12K req/s with 625-783% CPU shows Helidon's virtual threads keeping DB connections busy without over-scheduling. No 5xx errors across any profile, which is great stability-wise. Looks ready to ship. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Helidon SE 4.4.0
Adds Helidon SE — Oracle's cloud-native Java framework with its own Níma WebServer built entirely on Java 21 virtual threads.
Why Helidon?
HttpArena already has several JVM frameworks but they all use either Netty or Tomcat as their underlying server:
Helidon SE 4 is the only JVM entry with its own custom web server (Níma) that uses a thread-per-request model on virtual threads instead of event loops. This makes it a genuinely different architecture to benchmark against the reactive/event-loop entries.
Implementation
Endpoints
Validation
Notes
Helidon 4 rewrote the SE API from async/reactive to blocking (enabled by virtual threads). The result is simpler code that still gets high throughput — will be interesting to see how it stacks up against the Netty-based frameworks.
cc @tomas-langer @spericas (Helidon maintainers)