A JVM service runs in a container capped at 512 MB and keeps getting killed by the kernel, even though its heap usage looks small and it never throws `java.lang.OutOfMemoryError`. How does a modern JVM discover container CPU and memory limits, and how would you size it so this stops happening?

## Why the kill happens with no OutOfMemoryError Two different budgets are in play. `-Xmx` bounds the Java heap; the container's cgroup limit bounds the **resident set size of the whole process**. When the heap is exhausted the JVM throws `java.lang.OutOfMemoryError`, which you see in the logs. When the cgroup limit is exceeded the kernel sends SIGKILL — uncatchable, no log line, exit code 137 with `OOMKilled: true`. A silent death alongside a healthy-looking heap is the signature of the second case. Everything outside the heap still counts against the limit: - **Metaspace**: class metadata, unbounded by default; frameworks that generate classes grow it steadily. - **Thread stacks**: roughly 1 MB each on 64-bit, so 300 threads is ~300 MB — often the single biggest surprise. - **JIT code cache** and compiler arenas. - **GC overhead**: card tables, remembered sets, region metadata — a few percent of heap, more for region-based collectors. - **Direct and mapped byte buffers**: NIO, pooled network buffers, memory-mapped files. - **Native allocations**: database drivers, compression, TLS, and glibc malloc arenas, which can retain a surprising amount of freed-but-unreturned memory (`MALLOC_ARENA_MAX=2` is a common mitigation). ## How the JVM sees the container Historically the JVM read `/proc/meminfo` and the host CPU count, so a container limited to 512 MB on a 64 GB host would default its max heap to about 16 GB and die almost immediately. `-XX:+UseContainerSupport`, added in JDK 10 and backported to 8u191, made the JVM read the cgroup instead: `memory.max` for the memory ceiling and `cpu.max` (quota over period) for the processor count. It is enabled by default. Two caveats matter. First, the default heap is a **fraction** of the container limit — historically `MaxRAMFraction=4`, now expressed as `MaxRAMPercentage`, defaulting to roughly 25% for containers of meaningful size. That conservatism leaves room for the non-heap regions above, but it also means a 512 MB container defaults to about a 128 MB heap, which is often why an app instead OOMs *inside* Java on small containers. Second, **cgroup v2** detection required a newer JVM (JDK 15, later backported into 11.0.16+ and 17.x); an older JDK on a v2-only host falls back to host values and mis-sizes everything. CPU awareness follows the same path: active processor count is derived from the CPU quota, and that number drives GC thread counts, JIT compiler threads, the common ForkJoinPool, and any library that calls `Runtime.availableProcessors()`. `--cpus=0.5` therefore yields one reported processor, changing GC and pool sizing rather than merely slowing execution. This is not JVM-specific — Go and .NET have equivalent container-awareness stories, and older runtime versions in all three ecosystems read host values. ## Sizing method 1. **Measure the real total.** Run under representative load and watch RSS against the limit, plus Native Memory Tracking (`-XX:NativeMemoryTracking=summary`, then `jcmd <pid> VM.native_memory summary`) to attribute non-heap usage. 2. **Budget explicitly.** Prefer `-XX:MaxRAMPercentage` (say 60–75% for a service with modest native usage) over a raw `-Xmx`, so the same image behaves sensibly when the limit changes. Bound `-XX:MaxMetaspaceSize` and `-XX:MaxDirectMemorySize` so runaway non-heap growth surfaces as a catchable Java error instead of a kernel kill. 3. **Cap concurrency.** Thread pools and connection pools have a memory cost; unbounded pools defeat any heap budget. 4. **Leave headroom.** The container limit should exceed measured peak RSS by a real margin — typically 20–50% — because the limit is a cliff, not a slope. 5. **Prefer failing inside the JVM.** An `OutOfMemoryError` with a heap dump (`-XX:+HeapDumpOnOutOfMemoryError`, written to a mounted volume) is diagnosable; a SIGKILL is not. Tight internal bounds plus a slightly larger container limit buy exactly that. ## Sanity checks `java -XX:+PrintFlagsFinal -version` inside the container prints the effective `MaxHeapSize` and `ActiveProcessorCount` as the JVM computed them — the fastest way to prove whether container detection worked. If `MaxHeapSize` looks like a quarter of the *host's* RAM rather than the container's, you are on an old JDK, on cgroup v2 without support, or someone disabled container support explicitly.