Every time you configure a Java application's heap size, you are essentially making a trade-off: spending more on infrastructure to improve performance metrics such as throughput or latency. Historically, this trade-off was visible when an undersized heap triggered long pauses, signaling a need for more resources. With modern collectors, however, pause duration and computational effort have become decoupled. This creates an operational blind spot: dashboards may show excellent response times, while the collector silently consumes excess compute capacity to compensate for a constrained heap. To address this, it is essential to look beyond GC pauses and examine overall efficiency using new tools. This article, therefore, analyzes why we need additional metrics for infrastructure efficiency and introduces the new MemoryMXBean.getTotalGcCpuTime() API in Java 26 (OpenJDK 26), which empowers engineers and researchers to quantify the collector's CPU overhead and make informed memory-CPU trade-off decisions.