[External] : Re: Moving Forward with AHS for G1

[Erik Osterlund]

> On 15 Apr 2025, at 23:27, Man Cao <manc at google.com> wrote:
> 
> 
> > > One example is that the custom container has a custom implementation for soft limit, and still uses cgroup memory limits as hard limit. Apps that are "good citizens" should strive to stay below the soft limit.
> > That’s exactly what the purpose of memory.high is. With cgroups v2, memory.high is a soft limit while memory.max is a hard limit. AHS should respect both really.
> 
> Supporting both memory.high and memory.max for AHS sounds great.
> The soft limit for the custom container is only one example. The custom container also has "strange" use cases where the actual limit is larger than cgroup's hard memory limit.

Okay, great. Sounds like AHS + actually using the standardized cgroups memory limits as the way of limiting memory is a viable path forward then?

> Going back to the high level, the point is that it is impractical for organizations such as us to change deployment environments (e.g. migrating from custom container to standard container) in order to use AHS. A flag such as CurrentMaxHeapSize will definitely help these use cases adopt AHS.

So the main point for introducing CurrentMaxHeapSize, as opposed to going directly to AHS, would be to support all the people out there that already built their own adaptive container infrastructure that doesn’t use industry standard cgroup technology to limit memory. Instead, this group of users use the very proposed CurrentMaxHeapSize functionality (which obviously does not exist in mainline yet) to limit memory adaptively instead.

I have to be honest… this sounds like a niche feature to me with a ticking clock attached to it. Yet if it gets integrated, we will not be able to get rid of it for decades and it will cost maintenance overheads along the way. So I think it would be good to see a prominent use case that might be interesting for a long time going forward as well, and not just a way to help you guys stop using the proposed feature in the transition to AHS, which seems to be where we are going.

I think what will reach a much broader audience going forward, is AHS. And if that’s the feature we really want, I can’t help but wonder if exposing this user configurable stuff along the way is helping towards that goal rather than slowing us down by inventing yet another set of manually set handcuffs that the JVM and AHS will have to respect for ages, way past its best before date.

/Erik