Beyond the Java heap, what else consumes memory in a running JVM process, and how do you put an explicit bound on each part when budgeting a service's total memory footprint?

## Why the inventory matters Any statement of the form 'this service needs N gigabytes' is wrong unless it accounts for everything the operating system charges the process for. The heap is the part everyone tunes and often not much more than half of the total. Each of the remaining regions has a default, and most of those defaults are either unbounded or derived from the heap size, which is how a carefully chosen -Xmx still produces an unpredictable footprint. ## Class metadata Class metadata - the runtime representation of loaded classes, methods and constant pools - lives in metaspace, which is native memory outside the heap. Its default maximum is effectively unlimited, so a framework that generates proxies, or a classloader that is never released, grows native memory until something external intervenes. -XX:MaxMetaspaceSize converts that into a clear, attributable failure at a chosen boundary. On 64-bit JVMs using compressed class pointers there is also a separate compressed class space, reserved at 1 GB by default and controlled by -XX:CompressedClassSpaceSize; it is reserved address space rather than committed memory, but it matters for address-space accounting. ## Compiled code The JIT compiler stores compiled methods in the code cache, reserved at roughly 240 MB under tiered compilation and settable with -XX:ReservedCodeCacheSize. Large applications with many hot methods can genuinely fill a modest cache; when it fills, the JVM disables compilation and performance collapses, so shrinking this to save memory is a trade with a sharp edge. -XX:+UseCodeCacheFlushing lets it evict cold code instead. ## Thread stacks Each platform thread gets its own stack, sized by -Xss and typically 512 KB to 1 MB by default. The stack is reserved on creation and becomes resident as it is actually used, so a thousand threads is a gigabyte of address space and a smaller but real resident cost. The controlling variable is almost always thread count, not stack size: bounded pools, avoiding a thread per connection, and using virtual threads where the workload suits them do far more than shaving -Xss, which mainly risks StackOverflowError on deep recursion. ## Off-heap buffers Direct byte buffers are allocated outside the heap and are reclaimed only when their Java handles become unreachable and are processed, so their lifetime is coupled to collection timing in a way ordinary allocation is not. Their maximum defaults to the value of -Xmx, meaning a service with a 4 GB heap may implicitly permit another 4 GB of direct memory; -XX:MaxDirectMemorySize should be set deliberately. Memory-mapped files add another category: resident memory backed by the page cache, which the kernel can reclaim but which still shows up in process accounting and in container charging. ## Collector overhead Every collector keeps metadata proportional to the heap: mark bitmaps, per-region remembered sets, forwarding or relocation tables, and card structures. A few percent of heap is a reasonable planning figure for a region-based collector, with some collectors and some workloads considerably higher. This is memory you cannot switch off, and it is one reason a very large heap costs more than its nominal size. ## Native and allocator overhead JNI libraries, compression and cryptography implementations, and drivers allocate native memory the JVM does not track. On glibc, each thread can acquire its own malloc arena, so many-threaded services show resident memory noticeably above the sum of the JVM's own accounting; MALLOC_ARENA_MAX limits this. Symbol tables, string tables and JVM-internal structures add a smaller fixed cost. ## Turning the list into a number Budget as: maximum heap, plus metaspace cap, plus code cache, plus thread count times stack size, plus direct memory cap, plus a collector-overhead allowance, plus native slack. Then stop trusting the arithmetic and measure: run with -XX:NativeMemoryTracking=summary and take jcmd VM.native_memory summary snapshots under representative load, which attributes reserved and committed memory by category and immediately shows which assumption was wrong. Use the baseline and diff facility to see which category grows over a long soak - that is how an unbounded consumer is identified before it terminates the process.