Graalvm on tsvinc

Eight Connections, Zero Available

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

Part 18 of the Micronaut native image series. Follows Part 17, which found that reactive and imperative produced identical throughput on the 28-API workload. Assumes familiarity with R2DBC and Project Reactor.

60.8 and 59.9

Two frameworks. Different HTTP servers, different dependency trees, different teams maintaining them. Under load, both reactive stacks land at almost the same throughput:

Framework	Model	Runtime	Mem	rps	p95	k6 errors
Micronaut	Reactive	Native	128 MB	60.8	15000.6 ms	14.1%
Spring Boot	Reactive	Native	128 MB	59.9	13548.7 ms	2.0%
Micronaut	Imperative	Native	256 MB	251.9	2554.8 ms	0%
Spring Boot	Imperative	Native	256 MB	220.6	2588.9 ms	0%
Quarkus	Reactive	Native	256 MB	258.7	—	0%

Imperative hits 220–252. Quarkus reactive hits 259. Micronaut and Spring Boot reactive: 60.

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.

16,700 Classes Before Your First Request

Mon, 06 Jul 2026 00:00:00 +0000

Part 24 of the memory benchmark series. Assumes familiarity with JVM memory regions and container memory limits.

96% at Idle

Quarkus JVM, jdbc-synth scenario, 256 MB container (--memory=256m, swap disabled). The app starts. Prometheus reports heap usage: 37 MB used out of a 62 MB cap. Healthy. Normal. Unremarkable.

Container RSS at idle: 246 MB.

The first k6 ramp hits, allocates a few buffers, and the OOM killer fires. Twenty-six restarts. 42.8 req/s. 53% error rate. FAILED.

Four Bugs the Tests Couldn't See

Sun, 05 Jul 2026 00:00:00 +0000

Part 24 of the memory benchmark series. Follows Part 23, where six HTTP client swaps each OOM’d differently. Assumes familiarity with R2DBC, Hibernate Reactive, and connection pooling.

The senior code review on the first reactive port – Spring Boot 4.1 WebFlux and Quarkus 3.33 Hibernate Reactive, same app, same tests – came back clean. Field mapping: correct. Fan-out concurrency: correct. Scoring logic: correct. Native image hints: correct. Retry semantics: fixed (that was Part 21). All tests green.

Six OOMs and a Connection Pool

Sun, 05 Jul 2026 00:00:00 +0000

Part 23 of the Micronaut native image series. Follows Part 22, where the reactive ports reached throughput parity across three frameworks. Assumes familiarity with Spring’s RestClient and GraalVM native image.

The same 28-API fan-out app runs comfortably at 256 MB on Quarkus. Runs comfortably on Micronaut. On the imperative Spring Boot 4.1 port – Spring MVC, virtual threads, JdbcClient – it OOM’d. Then I fixed it and it OOM’d differently. Six benchmark runs. Six different failure modes. Each one peeling back a layer of what “choosing an HTTP client” actually means in a memory-constrained native image.

Three Front Doors, One Engine

Sun, 05 Jul 2026 00:00:00 +0000

Part 22 of the Micronaut native image series. Follows Part 21, where a retry was mistranslated two ways. Assumes familiarity with reactive Java (Mono/Flux/Uni) and at least one of the three frameworks.

The experiment

Same app. Same Java 25. Same GraalVM CE 25. Same Postgres. Same Liquibase schema. Same benchmark harness. Three frameworks.

The app fans out to 28 HTTP APIs concurrently, computes risk scores across seismic, atmospheric, and space weather data, and writes one row to Postgres. Six endpoints. The heaviest hits all 28 APIs in four parallel blocks. Built on Micronaut 5.0.0 with reactive R2DBC. Ported to Spring Boot 4.1 and Quarkus 3.33.

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

Quarkus 12,563 vs Spring 820 (Both Numbers Are Wrong)

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

Part 18 of the Micronaut native image series. Follows Part 17, which found that reactive and imperative hit the same throughput ceiling. Assumes familiarity with Prometheus counters.

Two numbers that can’t both be right

The framework comparison benchmark finished. Three frameworks, same app, same k6 profile, same 256 MB native image container. The analysis script printed:

Spring Boot:  HTTP served:  820 requests   avg=2.341ms
Quarkus:      HTTP served:  12,563 requests  avg=1.892ms

Quarkus crushes Spring by 15x. Write the blog post. Ship the chart.

The Throughput Was Always 115

Thu, 02 Jul 2026 00:00:00 +0000

Part 17 of the Micronaut native image series. Follows Part 16, which compared reactive vs imperative on a lighter workload. Assumes familiarity with Project Reactor and virtual threads.

115

That’s the number. Requests per second. For all twelve scenarios.

Reactive R2DBC on native: 115. Imperative JDBC on JVM: 115. Virtual threads with loom-carrier: 114.5. Reactive on JVM with 512 MB memory limit: 115.2. Imperative on JVM unlimited: 115.1.

Twelve benchmark runs. Two codebases. Three runtime configurations. Six memory/container permutations each. 0% failure rate across the board. And the same number, over and over, like a metronome that doesn’t care what’s playing.

Designed a Reactive Benchmark. Imperative Won.

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

Part 16 of the Micronaut native image series. Follows Part 15, which benchmarked the reactive service alone. Assumes familiarity with Project Reactor and virtual threads.

The Hypothesis

The workload was designed to make reactive shine. Six endpoints exercising parallel fan-out, scatter-gather, bounded concurrency, and backpressure. A Go mock server injecting realistic latency jitter — ISS at 10-50ms with 3% failures, NEO at 30-150ms, connection resets via Hijack() + conn.Close(). k6 ramping to 200 VUs then sustaining 500 req/s constant arrival. If reactive Micronaut had a home-court advantage anywhere, it was here.

265 req/s on All Three Runtimes (Until You Add a Memory Limit)

Sat, 27 Jun 2026 00:00:00 +0000

Part 15 of the Micronaut native image series. Assumes familiarity with reactive Java (Mono/Flux) and container memory limits.

The Draw

Native image, JVM, and virtual threads walk into a benchmark. Same reactive Micronaut service. Same k6 load profile. Same PostgreSQL. Same mock APIs with realistic latency jitter.

Runtime	Req/s	Errors	RSS (avg)
Native (unlimited)	264	1.0%	273 MB
JVM (unlimited)	266	1.0%	551 MB
Virtual threads (unlimited)	265	1.0%	543 MB

265 req/s. All three. The error rates match the mock server’s configured failure rate — the application itself isn’t failing. Reactive code runs identically on native image, HotSpot, and loom-carrier Netty.

Error Is Not Exception: Micrometer's Silent CPU Metric on Native Image

Mon, 22 Jun 2026 00:00:00 +0000

Part 13 in the Memory Benchmark series.

The catch block that catches nothing

This code has a bug. Not a typo, not a logic error. A type hierarchy bug.

private double invoke(@Nullable Method method) {
    try {
        return method != null
            ? toDouble((Number) method.invoke(operatingSystemBean))
            : Double.NaN;
    }
    catch (IllegalAccessException | IllegalArgumentException
           | InvocationTargetException e) {
        return Double.NaN;
    }
}

That’s micrometer’s ProcessorMetrics.invoke() (v1.16.5). It calls JMX methods via reflection, wraps the call in three catch clauses. Standard defensive coding.

We Removed Reactor. Nothing Got Slower.

Sat, 20 Jun 2026 00:00:00 +0000

We took the entire reactive stack out. R2DBC, Mono, Flux, Reactor Core, loom-carrier, flatMap with its carefully-tuned concurrency arguments. Replaced it with JDBC, HikariCP, and blocking method calls. Same endpoints. Same Netty HTTP server. Same PostgreSQL. Same k6 load profile: 10 to 200 VUs, 500 req/s constant arrival rate, seven scenarios each.

Throughput didn’t move. Latency dropped. Memory dropped. GC pauses dropped 63% at 256 MB.

The Scoreboard

This is part of the series benchmarking a Micronaut 5.0.0 app under memory constraints. The reactive version is the one from Part 10 and Part 11 — fully tuned, flatMap concurrency bounded, R2DBC pool sized to match, loom-carrier enabled for virtual threads. The imperative version: JDBC/HikariCP, THREAD_PER_TASK executor for virtual threads, same pool size.

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:

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.

The Observability Tax: When Metrics Cost More Than Your App

Thu, 28 May 2026 00:00:00 +0000

Add observability to understand your app’s memory usage. Watch observability consume all the memory.

The JVM at 128 MB worked in Part 2. It no longer works.

What Changed

One dependency:

<dependency>
    <groupId>io.micronaut.micrometer</groupId>
    <artifactId>micronaut-micrometer-registry-prometheus</artifactId>
    <scope>runtime</scope>
</dependency>

Three lines of YAML:

micrometer:
  export:
    prometheus:
      enabled: true

Prometheus endpoint exposed, micrometer collecting JVM metrics — heap, non-heap, GC pauses, threads, CPU, R2DBC pool stats. The standard production observability setup.

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.

Micronaut 5 Native Image: 14 Entries vs 1,913

Sat, 23 May 2026 00:00:00 +0000

Micronaut 5.0.0 dropped on May 20, 2026. The launch blog post promises first-class GraalVM native image support. The documentation is correct. It is also incomplete in ways that cost hours.

This is what building a non-trivial native image app looks like on day one: 4 HTTP clients hitting real APIs, reactive R2DBC pipeline into PostgreSQL, Liquibase migrations, @Scheduled cron jobs, Swagger UI. Everything that should Just Work and mostly does — except when it doesn’t, and the failure modes are silent.