Dynamic Heap Memory

DynamicHeapMemory.md

• No more Xmx! - Adaptable Heap Sizing for Containerized Java Applications

• JEP draft: Dynamic Max Memory Limit

  • RFR: 8204088: Dynamic Max Memory Limit (T. Schatzl)

• JEP 346: Promptly Return Unused Committed Memory from G1

• ZGC | Using -XX:SoftMaxHeapSize

• JDK-8238687: Investigate memory uncommit during young collections in G1

  • In JDK-8238687 G1 will make committed heap more or less follow the GCTimeRatio. Which means that there may be throughput regressions due to keeping a smaller heap now...
  • JDK-8247843: Reconsider G1 default GCTimeRatio value
  • JDK-8243672: Short term pause time ratio calculation in G1 off
  • JDK-8244603: G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs

• RFC: Adaptively resize heap at any GC/SoftMaxHeapSize for G1 (T. Schatzl)

  • The best approach I thought of has been to introduce a lower GCTimeRatio that G1 tries to stay above by resizing the heap. Effectively, G1 then tries to stay within ["LowerGCTimeRatio", GCTimeRatio] for its actual gc time ratio.

• HotSpot Attach API

• JVM Dynamic Attach utility (by A. Pangin)

  • A native client which implements the client side of the HotSpot Attach API and can load a Java agent into a HotSpot JVM.

• Example on how to get access to the JmmInterface defined in jmm.h (see java.management/share/native/libmanagement/management.c)

  • If compiling this into an agent independantly from the JDK, we have to copy the definition of JmmInterface from jmm.h and get a pointer to JVM_GetManagement() from libjvm.so dynamically at run-time by calling dlsym(). See async-profiler/src/vmEntry.cpp for an example.

• sun.management.HotspotInternal: the HotspotThreadMBean allows to query the CPU time of internal (e.g. GC, JIT,..) JMV threads. Also see my The HotSpot internal sun.management MBeans gist.

• JDK-8315149: Add hsperf counters for CPU time of internal GC threads added by Google in JDK 22.