Expected Behavior
Would be nice to add support cgroups v2 to Gradle, so that it can run more efficiently and stable in Docker.
Current Behavior (optional)
Gradle 8.1+ added support for cgroups v1 recently, but v1 is already obsolete. For example, Docker 20+ generally uses only v2. This means that Gradle doesn't take into account the actual memory limit when run in Docker, which often leads to build crashes due to exceeded memory limits. Current workaround for this is to have unreasonably high limits.
Context
A typical use-case for CI/CD is to have a Jenkins instance + a k8s cluster, which starts a pod for each build. Usually this pod would have limited CPU and memory resources, done with Docker/cgroups. Since Gradle doesn't support cgroups v2 and thus it doesn't know the actual limits, it makes it very easy for Gradle build to fail exceeding the memory limit. The issue is made worse by the fact that Gradle usually starts more workers than configured, keeping them idle in memory.
Expected Behavior
Would be nice to add support cgroups v2 to Gradle, so that it can run more efficiently and stable in Docker.
Current Behavior (optional)
Gradle 8.1+ added support for cgroups v1 recently, but v1 is already obsolete. For example, Docker 20+ generally uses only v2. This means that Gradle doesn't take into account the actual memory limit when run in Docker, which often leads to build crashes due to exceeded memory limits. Current workaround for this is to have unreasonably high limits.
Context
A typical use-case for CI/CD is to have a Jenkins instance + a k8s cluster, which starts a pod for each build. Usually this pod would have limited CPU and memory resources, done with Docker/cgroups. Since Gradle doesn't support cgroups v2 and thus it doesn't know the actual limits, it makes it very easy for Gradle build to fail exceeding the memory limit. The issue is made worse by the fact that Gradle usually starts more workers than configured, keeping them idle in memory.