Jvm on tsvinc

Native Image Grew to 734 MB

Tue, 07 Jul 2026 00:00:00 +0000

Part 20 of the Micronaut native image series. Field notes from running benchmark scenarios across 18 branches — three frameworks, three runtimes, four memory tiers. No narrative arc. Just five things that surprised me.

1. Native is not automatically small

The pitch: GraalVM native images are lean. Sub-100 MB footprint. Container-friendly. Cloud-native.

The CRUD workload confirms this. Native RSS across all frameworks ranges from 31 to 86 MB. JVM containers running the same code: 351-643 MB. The marketing copy is accurate — for CRUD.

Seven Fixes, Zero Errors

Fri, 12 Jun 2026 00:00:00 +0000

The fix for “JVM dies at 256 MB under load” was not a JVM flag.

Part 4 ended with Serial GC — the only GC that fits in 256 MB — serving 4,550 requests before the OOM killer showed up. 81% error rate. Same flags, same container, same load profile. Seven code changes later: 1,740,000 requests. Zero errors.

No GC tuning. No new JVM flags at all. The problem was never the runtime. It was the code asking the runtime to hold things it didn’t need to hold.

Your JVM Reports 151 MB. Your Container Uses 248.

Fri, 05 Jun 2026 00:00:00 +0000

151 MB. That’s what micrometer-prometheus reports for the JVM at 256 MB after serving 1.66 million requests. Heap 35 MB, metaspace 72 MB, compressed class space 13 MB, code cache 16 MB, direct buffers 0.75 MB. Add it up. 137 MB. Rounded generously: 151 MB with some measurement timing jitter.

Docker stats says 244.2 MiB. Out of 256 MiB. 95.38%.

The Visible Budget

After 1.66 million requests, Serial GC, -Xms64m -Xmx64m -Xss256k, here’s what the JVM admits to owning:

107 MB of Invisible JVM RAM

Tue, 02 Jun 2026 00:00:00 +0000

Prometheus says 137 MB. Docker says 244 MiB. /proc/PID/smaps is the only witness that doesn’t lie.

The Discrepancy

JVM at 256 MB, Serial GC, after serving 1.66 million requests. Measured at idle:

Docker stats:         244.2 MiB / 256 MiB  (95.38%)
Prometheus reports:
  Heap used:           35 MB  (Eden 4.4 + Survivor 0.1 + Tenured 30.5)
  Non-heap:           101 MB  (Metaspace 71.9 + CompClass 12.7 + CodeCache 16.3)
  Direct buffers:     0.75 MB
  ────────────────────────────
  Total visible:      ~137 MB

Gap:                  107 MB

107 MB that no JMX MBean exposes. No micrometer gauge records it. No Grafana dashboard shows it. To know it exists, you exec into the container and parse kernel memory maps.

Every GC Failed at 256 MB (Except the Boring One)

Sun, 31 May 2026 00:00:00 +0000

Monday: “The JVM at 256 MB should work. Just need the right GC.”

Tuesday: G1GC. OOM at 150 concurrent users.

Tuesday, later: Shenandoah. OOM at 50 concurrent users.

Tuesday, even later: ZGC. OOM at zero concurrent users. Couldn’t serve a single request.

Wednesday: Serial GC with 7 JVM flags and 3 Micronaut properties. Survives 60 seconds before the OOM killer shows up anyway.

The Contenders

Same app: Micronaut 5.0.0 Space Observatory, 16 REST endpoints, reactive R2DBC, 7-table PostgreSQL schema. Container: 256 MB hard limit, swap disabled. Heap capped at 64 MB (-Xms64m -Xmx64m). Load: k6, ramping from 10 to 200 concurrent users over 8.5 minutes.

Native Image vs JVM at 128 MB: The Benchmark Nobody Warned Me About

Tue, 26 May 2026 00:00:00 +0000

The mental model: native image uses less memory, therefore native image performs better under memory pressure.

This is wrong.

Setup

The app: Micronaut 5.0.0 Space Observatory. 4 HTTP clients, reactive R2DBC into PostgreSQL, 7-table schema, 16 REST endpoints. Real enough to matter. (Part 1 covers the build.)

Four scenarios, clean database each time (docker compose down -v):

Native, unlimited memory – baseline
Native, 128 MB hard limit – mem_limit: 128m, swap disabled
JVM, unlimited memory – same app, java -jar
JVM, 128 MB hard limit – same container constraint

Load: Apache Bench, 1,000 requests x 20 concurrent, container-to-container. DB endpoints only – no external API calls polluting the numbers. Host: 16 cores, 32 GB RAM, Linux 7.0.9.