code-cache-segmentslisted

# Code Cache Segments ## Purpose On JDK 17-25, treat the normally segmented code cache as three independent allocators with separate ceilings. One `CodeHeap` can sit at 99.8% while the consolidated number reads 72%, and every tool that stops at the consolidated line reports a healthy system. Allocation fallback already exists in JDK 17: pressure in one heap can send tier-3 code into the heap normally used for non-profiled code. Separately, since JDK 20, GC-driven unloading has replaced the sweeper, and code-cache GC triggers use aggregate pressure rather than detecting an individual full heap. A code-cache-full compiler stop occurs when allocation cannot be satisfied after the applicable fallback. Do not hard-code a count of three into tooling: unsegmented and interpreter-only modes have fewer heaps, and later HotSpot builds can add heap kinds. Discover the runtime shape from `Compiler.codecache` and `jdk.CodeCacheConfiguration`. The second failure this prevents is the reflexive "double `ReservedCodeCacheSize`". With default sizing, extra capacity is shared between the nmethod heaps; it does not proportionally raise `non-nmethods`. More capacity can also change code-cache GC frequency. Establish which mechanism is responsible before choosing a larger total or a different split. ## Workflow Before collecting evidence, pin vendor/update, architecture, collector, compiler mode and effective startup flags from the deployed runtime and its CI/image configuration. The command