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. Since JDK 20 the consequence of one full heap is not "the compiler stops": the allocator falls back to the other nmethod heap, so short-lived tier-3 code starts landing in the heap that was reserved for long-lived C2 code, and the GC-driven unloading that replaced the sweeper keys off the **aggregate** free ratio and does not notice. Compilation stops only when the 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`". It works when the pressured segment happens to be one of the two that split the remainder 50/50, and wastes half the increase when it is not — or when the real cost was the GC pauses the code cache was triggering, which a bigger cache also fixes, for a different reason. ## Workflow Before collecting evidence, pin vendor/update, architecture, collector, compiler mode and effective startup flags from the deployed runtime and its CI/image configurati