### Abstract

The JVM was designed for a long-lived process on a dedicated machine with all the memory it could see. A container is the opposite of that in every respect: short-lived, sharply constrained, and scheduled by something that will kill it without ceremony the moment it crosses its memory limit. The defaults were tuned for the first world and your service runs in the second.

This talk is about closing that gap for Quarkus workloads. We will look at what the JVM actually perceives from inside a container, where its ergonomics guess wrong, and what you can do about startup time, resident memory, and throughput — including the honest accounting of which of those three you are giving up when you improve the other two.

**What you'll learn:**

- Read what the JVM sees inside a container — cgroup limits, CPU quota versus shares, and the specific places ergonomics draw the wrong conclusion
- Cut startup time with AppCDS and the AOT cache, and judge when native compilation earns its build-time cost
- Size heap against non-heap correctly, so the OOM killer stops being an unplanned part of your architecture
- Measure the tradeoff triangle — startup, throughput, footprint — and pick the two that matter for your workload
- Tune differently for the scaling pattern you actually have: steady long-running services versus scale-to-zero

**Demos:** one service built five ways — default JVM, tuned JVM, AppCDS, AOT cache, native — measured for startup, resident memory, and throughput under load; a pod reproducibly OOM-killed and then fixed; garbage collector choice changing behaviour under a tight CPU quota.

**Key Takeaways:**
Attendees leave able to explain where their Java service's memory actually goes, why it starts as slowly as it does, and which lever to pull for their particular deployment shape. The numbers from the demos are less important than the method for producing your own.

This is not a benchmark shootout, and it will not end with a recommendation to use native mode for everything. It is about knowing precisely which number you are trading away.

### Level of Expertise

Intermediate — attendees should write Java and have deployed something to Kubernetes or OpenShift. No prior JVM tuning experience assumed.

### Target Audience

Java developers, architects, and platform engineers running JVM workloads on Kubernetes or OpenShift — particularly anyone who has been handed a memory limit by a platform team and asked to make it fit.

Requirements:

Laptop
Browser
Github account
Basic Java Skills