AHS is supposed to work well in multi-process situations, in the discussion at https://mail.openjdk.org/pipermail/hotspot-gc-dev/2026-January/057644.html [~eosterlund] brought up some interesting case where G1 should not expand the heap thoughtlessly:

----------
If I understand the conversation, what is referred to is something like this in ZGC style AHS:
https://github.com/openjdk/zgc/blob/c87666fbda432c9c9d19d6871859b8c195476f6c/src/hotspot/share/gc/z/zAdaptiveHeap.cpp#L505

and:
https://github.com/openjdk/zgc/blob/c87666fbda432c9c9d19d6871859b8c195476f6c/src/hotspot/share/gc/z/zAdaptiveHeap.cpp#L515

The reasoning here is that if you have a process that utilizes 1% of the machine CPU resources but 50% of the memory resources, you might not want to bloat memory with lots of garbage to reduce fraction of that 1% that is spent of GC. In that situation, having a 100% CPU overhead so that the JVM uses 2% of the overall machine CPU, while saving a huge amount of the available RAM, is preferable. In other words, the CPU overhead target depends on the resource balance of unused machine resources, as well as a resource balance of the process used resources.

In terms of use cases, containers without resource constraints or partial resource constraints, is one application. Multi process situations would be another one.

--------

Apart from this particular issue, improve G1 AHS policy in such multi-process setups.