I've been working on my own version of this, and there is a few of problems with this approach:

1. This only works for cgroups v1. In cgroups v2, there is a "unified hierarchy" where it lives at /sys/fs/cgroup/memory.max/memory.current.
2. When there is no limit, the number in memory.limit_in_bytes (cgroups v1) is a huge number 9223372036854771712. For memory.max (cgroups v2) it is the string max. In this case, you can't use these values - you need to read from /proc/meminfo to get the total actual system memory.
3. Not sure how much this appears in practice, but it's possible to mount the cgroup filesystems in a different directory to /sys/fs/cgroup. The best way to handle this would be:
   i. Read /etc/mtab and look for cgroup2 or cgroup .... memory entries
   ii. If these exist, use them
   iii. If they don't exist, try the default /sys/fs/cgroup path

I can make a PR with the code I have (although might have to wait until Monday, as it's getting late here in London).

Thanks for the insight here. 1 and 3 are good points, but also items I think that could be addressed as follow up work (i.e. we could deliver cgroup1 support at the default location in this PR and then add support for cgroup2 later). I think item 2 is not an issue because when the cgroup1 value is a huge number, we always select the smaller of the cgroup value or the meminfo value. Assuming we also support cgroups v2 in the future, when it's "max" we would just drop out and not consider the cgroup value (i.e. non-numeric value), defaulting to meminfo.

More than happy for this to be merged in as is, it should fix our issues in CI at least. My code unfortunately targets Java 8, rather than 6, so can't immediately get it working when pasted into this repo, but here it is for posterity.

@ghale is there by any chance any ticket for supporting cgroup2 also?

Would it also be possible to backport this to Gradle 7? We've started migrating to Gradle 8, but we have over 100 plugins written over 10 years and 1000s of repos, so it takes us a good long while. Without the backport I'm going to have continue to build my plugin that swaps out the OsMemoryInfo service using reflection as a stopgap for Gradle 7, which would be a real pain (we're acutely feeling the pain of this issue atm).

It's definitely possible. I'll see what we can do.

Sorry to resurrect an old thread but was this ever backported? I can't find it in the release notes for 7.6.2 but just want to confirm.

Unfortunately, this got lost in the noise and didn't get included in 7.6.2. I've made sure it's on the list to be included in 7.6.3.