chaos: log cgroup memory limit and trim aarch64 heap to stop OOMKills

Measured on matching-arch hosts: this workload floats at ~2.6-2.75GB RSS
regardless of MALLOC_CHECK_/allocator tuning, ruling that out as the OOM
cause. Trim -Xmx to 1536m on aarch64 for real headroom, and log the
container's actual cgroup memory limit so future OOMs are diagnosable
from the job log directly.

Author: jbachorik

utils/run-chaos-harness.sh

@@ -182,6 +182,23 @@ case $ALLOCATOR in
 esac
 echo "LD_PRELOAD=${LD_PRELOAD:-}"
 
+# Log the actual container memory ceiling (if any) so OOMKilled failures are
+# diagnosable from the CI job log directly, instead of having to infer it
+# from RSS measurements on a separate repro host.
+CGROUP_MEM_LIMIT=$(cat /sys/fs/cgroup/memory/memory.limit_in_bytes 2>/dev/null || cat /sys/fs/cgroup/memory.max 2>/dev/null || echo "unknown")
+echo "cgroup memory limit: ${CGROUP_MEM_LIMIT}"
+
+# Measured on a matching-arch host: this workload's RSS floats around
+# 2.6-2.75GB at -Xmx2g regardless of allocator/malloc tuning (confirmed the
+# aarch64 CI OOMs are not caused by MALLOC_CHECK_'s per-chunk overhead -
+# RSS was the same or higher with it disabled), meaning the container's
+# actual memory ceiling sits at or below that. Trim the heap on aarch64 to
+# give real headroom instead of re-tuning allocator env vars again.
+HEAP_MB=2048
+if [ "$(uname -m)" = "aarch64" ] || [ "$(uname -m)" = "arm64" ]; then
+  HEAP_MB=1536
+fi
+
 HS_ERR="${CHAOS_ERROR_FILE:-${WORK_DIR}/hs_err.log}"
 rm -f "${HS_ERR}"
 
@@ -198,7 +215,7 @@ java -javaagent:${PATCHED_AGENT} \
      -Ddd.profiling.ddprof.nativemem.enabled=true \
      -Ddd.env=java-profiler-stability \
      -Ddd.service=java-profiler-chaos \
-     -Xmx2g -Xms2g \
+     -Xmx${HEAP_MB}m -Xms${HEAP_MB}m \
      -XX:MaxMetaspaceSize=384m \
      -XX:NativeMemoryTracking=summary \
      -XX:ErrorFile=${HS_ERR} \