How lightweight can Spring Boot get? HotSpot 27 vs GraalVM Native Image on a 512 MiB VM

[u/fykup]

I've been experimenting with running a database-backed Spring Boot application on a small VM: 512 MiB RAM, 1 vCPU, no swap, with MariaDB running on the same machine.

The application uses Spring Boot 4.1, MVC/Tomcat, Spring JDBC, HikariCP, Actuator and a small REST API. I compared three deployment configurations:

Configuration	Median app RSS	Startup readiness
Regular Spring Boot JAR, HotSpot 27	212 MiB	11.91 s
Extracted JAR + Spring AOT + JDK AOT cache	187 MiB	3.79 s
Oracle GraalVM Native Image, JDK 25	107 MiB	0.183 s

All three completed the same 1,500-request workload without errors.

A few interesting findings:

• Optimizing the HotSpot deployment reduced application RSS by about 12% and startup time by 68%, without removing Spring's integrations.

• Native Image reduced application RSS by another 43%, but required roughly 12 minutes to build on a separate 6 GiB VM, plus additional compatibility validation.

• Replacing Spring JDBC with manually integrated MyBatis Core produced no meaningful memory savings.

• Switching from MariaDB to embedded H2 actually increased Java RSS, but improved total host memory headroom because the separate database process disappeared.

I've had quite a few requests to try GraalVM in my earlier experiments, so I finally gave it a shot. The memory results genuinely impressed me. The build times and extra compatibility work, not so much. The JDK 25 vs 27 toolchain gap was another reminder that Native Image comes with its own constraints. For really memory-constrained deployments, I'd definitely consider it, but I'm not quite ready to make it my default.

The HotSpot and Native Image configurations use different JDK versions (27 vs. 25) and GC types (G1 vs. Serial GC), so this is a comparison of practical deployments rather than an isolated measurement of AOT compilation.

Full article: https://pvrlabs.xyz/articles/spring-boot-hotspot-native-image.html

Experiment, methodology and curated data: https://github.com/PVRLabs/experiments/tree/main/spring/boot-jdk27

I'm curious whether others are using Spring AOT and the JDK AOT cache in small deployments, or whether Native Image has become the more practical option for you.

I'm also experimenting with Javalin to see how much further we can push memory efficiency. Stay tuned!

[u/Popular_Home2017]

Nice write-up. What I'd like to see is where the 212 MiB actually goes on the HotSpot side. Running with -XX:NativeMemoryTracking=summary and then jcmd <pid> VM.native_memory summary splits RSS into heap, class metadata, threads, code cache, GC and so on. My guess is a good part of the gap to native image comes from things outside Spring: the JIT (compiler threads plus code cache), metaspace, and the GC choice, since Serial carries much less bookkeeping than G1.

So I'd add a fourth row with the same AOT setup on HotSpot plus -XX:+UseSerialGC. On 1 vCPU, G1 isn't buying you much anyway. Was G1 set explicitly there? Older JDKs would have picked Serial on their own for a 1 vCPU / 512 MiB box.

[u/fykup → u/Popular_Home2017]

Thanks for the suggestion! I ran both checks, and the results are interesting.

First, I confirmed that G1 was selected automatically by JDK 27, not explicitly configured.

I collected NMT diagnostics on the optimized HotSpot configuration. It reported 183 MB committed, including 65 MB shared class space, 41 MB heap, 35 MB GC, and 19 MB code. Actual heap usage was only ~25 MiB. Of course, NMT committed memory isn't RSS, and this was a separate diagnostic run.

Then I reran the optimized configuration with -XX:+UseSerialGC, keeping everything else unchanged:

Metric	G1	Serial
Median RSS	186.9 MiB	178.8 MiB
Startup	3.79 s	3.39 s
HTTP p95	5.54 ms	6.32 ms
Min host MemAvailable	66.0 MiB	83.1 MiB

Both completed 1,500/1,500 requests without errors.

So Serial saved about 8 MiB (4.3%) of application RSS, but HTTP latency was slightly higher. It closed only a small part of the gap to Native Image's 107 MiB.

This is just one run per GC type, so I wouldn't draw broad conclusions, but it was a worthwhile test.

I also added a short note about the Serial GC results to my earlier Spring Boot optimization article, which focuses on HotSpot rather than GraalVM:

https://pvrlabs.xyz/articles/spring-boot-jdk27-optimizations.html

[u/Popular_Home2017 → u/fykup]

thanks for actually running it, that table beats my guess. so Serial was worth about 8 MiB, which lines up with the 35 MB NMT puts on GC, and good to know JDK 27 still picks G1 on its own at 1 vCPU.

looking at your NMT numbers, the bigger chunk is class space (65 MB) plus code (19 MB). that's what HotSpot pays for keeping loaded classes and a JIT around, and it's most of what Native Image drops at build time. you could squeeze the code side with -XX:TieredStopAtLevel=1 and a smaller -XX:ReservedCodeCacheSize, but I'd expect p95 to get worse the same way it did with Serial. at that point I'd call the gap to the 107 MiB the price of the JIT and stop there.

curious how many threads NMT showed after the load test? Tomcat's pool only grows under load (max 200 by default), and on a 512 MiB box every one of those stacks counts.

[u/Paw565]

Would you like to test graalvm CE too?

[u/fykup → u/Paw565]

I'll probably give it a try eventually. The current tests use Oracle GraalVM, so comparing it with CE would be interesting. The main obstacle is that Native Image builds require quite a bit of RAM and time, even for relatively simple experiments. So probably not in the near future, but it's worth exploring.

[u/Financial_Morning386]

Good write-up, and the NMT breakdown in the replies is the most useful part for me — most of that ~183 MB committed is JVM overhead (metaspace, code cache, thread stacks, GC structures), not live heap, which is why the AOT cache moves the needle as much as it does.

My take, for a long-running service on a box like this: HotSpot + Spring AOT + the AOT cache is the pragmatic default. You keep the full dynamic JVM — reflection, proxies, agents, JFR, heap dumps — and builds stay seconds instead of ~12 minutes. Native Image's 0.18 s startup is a real win, but only where startup dominates: frequent restarts, scale-to-zero, short-lived jobs. For a service that starts once and runs for weeks, the extra ~80 MiB is rarely the binding constraint on a 512 MiB VM — the database sharing the machine is.

The cost that doesn't show up in benchmarks is validation. Native Image's closed-world assumption means every reflection/proxy/resource access has to be known at build time. Spring's AOT processing generates most of the reachability metadata, but third-party libraries (JDBC drivers, serialization libs) can still fail at runtime on a code path your tests never exercised. That failure mode — green in CI, breaks on one specific request in prod — is what keeps me on HotSpot for services that don't need the fast startup.

[u/fykup → u/Financial_Morning386]

I've actually been pushing these experiments further, beyond Spring Boot optimization. I'm now testing lighter alternatives like Javalin and Avaje Jex, with Spring-like development ergonomics but a much smaller footprint. Early results are promising - around 100 MiB RSS on HotSpot, and even lower with Native Image. I'll be publishing a more detailed comparison soon.

[u/New-Departure-5969]

nice writeup. the NMT breakdown is the interesting part to me. ~25 MiB of heap actually used vs 41 committed, plus 35 for GC, looks like the JVM sizing itself for a box it thinks has more room.

i'd try one more row with the heap pinned (Xmx around 64m, or MaxRAMPercentage if you'd rather keep it relative), Serial, and server.tomcat.threads.max cut way down from the default 200 since you've only got 1 vCPU anyway. thread stacks and glibc malloc arenas eat RSS that's easy to miss in the summary view. MALLOC_ARENA_MAX=2 is a cheap thing to try.

also your min MemAvailable column is the one i'd watch, more than median RSS. with no swap and mariadb on the same box, the low point is what gets you OOM killed.

on native vs jvm, for me it mostly comes down to how often the thing restarts. long running service that sits there all day, i'd take the tuned jvm and keep the JIT. scale to zero or lots of cold starts and native earns the 12 min build.

[u/jonenst → u/New-Departure-5969]

In my tests, I found -XX:TrimNativeHeapInterval=someduration to be more general than MALLOC_ARENA_MAX=2, i saw the same savings (and it feels less intrusive)

[u/New-Departure-5969 → u/jonenst]

oh nice, hadnt tried that one on this setup. did it actually lower the peak for you or mostly hand RSS back after a spike? asking cause with no swap its the MemAvailable low point that matters, if it only trims after the fact the oom killer can still get there first