Docker 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.

-Xmx Won't Save Your Native Image

Fri, 03 Jul 2026 00:00:00 +0000

Part 19 of the Micronaut native image series. Follows Part 18, where a reset Prometheus counter made the benchmark lie. Assumes familiarity with GraalVM native image and Docker memory limits.

The Confident Wrong Fix

# docker-compose.yml — the JVM reflex
environment:
  JAVA_TOOL_OPTIONS: "-Xmx128m"

Standard. Reliable. Every JVM deployment in every Kubernetes cluster in the world does this. It has never not worked.

It is a no-op on a native binary.

GraalVM native images are not JVMs. They don’t read JAVA_TOOL_OPTIONS. They don’t read -Xmx from environment variables. GraalVM issue #4650 requested this capability. Issue #9504 confirmed it’s still not supported. Your heap cap does nothing. No warning. No error. The binary starts, ignores the variable, sizes its heap however it wants.

Loom Carrier on a Reactive Stack: 78 MB for Free

Wed, 17 Jun 2026 00:00:00 +0000

“Virtual threads don’t help reactive apps.” You’ve heard this. Probably said it. The reasoning is sound: a fully reactive stack — Mono/Flux from HTTP client through R2DBC to Netty — never blocks a platform thread. Virtual threads solve blocking. No blocking, no benefit. QED.

We ran the benchmark anyway. The conventional wisdom is correct about throughput and wrong about everything else.

The Stack

Space Observatory: Micronaut 5.0.0, Netty, R2DBC PostgreSQL, Reactor Core, Micrometer. Reactive end-to-end — no subscribeOn(Schedulers.boundedElastic()), no blocking JDBC, no thread-per-request anywhere. GraalVM CE 25, Java 25.

Three Bugs in a Trenchcoat Pretending to Be One Hang

Sun, 07 Jun 2026 00:00:00 +0000

The CLAUDE.md for this project had a one-liner that persisted for a week: “Micronaut AOT hangs — keep disabled.”

Every developer who touched the project read that line, nodded, and moved on. AOT disabled. Property set to false. Life continued. Nobody questioned it because it was technically true — AOT had hung — and the project worked without it.

Then the benchmark numbers arrived. Non-heap at 119 MB. Container limit at 256 MB. JVM OOM-killing at 150 concurrent users. And a footnote in the Micronaut AOT docs: “build-time service loading reduces runtime metaspace by eliminating classpath scanning.”

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: