2.1 KiB
PR#134: Memory Limits for the Mutation Build
WARNING: This document describes only the change applied in this PR. It may already be outdated once the next PR is merged. Historic PR-documentation is not maintained along with new PRs — treat it as a snapshot, not as current documentation.
The Problem
The nightly mutation build nearly ran mih09 out of memory on 2026-10-09 (5.8 GiB RAM, 4 GiB swap, 3 CPUs). No other build ran at the same time.
| Measure | Average in the 2 h before | Peak during the run |
|---|---|---|
| RAM used | 3.3 GiB | 5.7 GiB |
| Swap used | 2.6 GiB | 4.0 GiB, all of it |
| Memory pressure | 1 % | 85 % |
| Load | 1.3 | 111 |
| IO pressure | 4 % | 72 % |
A PIT run starts a main process and one test process (minion) per thread, two by default. None of them had a heap limit, so each could grow to a quarter of the RAM, about 1.45 GiB on mih09. The JVM grows its heap rather than collect garbage while it may, so the three together pushed the host into swap.
Non-Goals
- No fewer threads: two minions keep the run at about 35 minutes.
- No change of the Gradle daemon, which already runs with Gradle's default of 512 MiB.
The Solution
pitest.mainProcessJvmArgslimits the main process to 768 MiB.pitest.jvmArgslimits each minion to 512 MiB and gives it the serial garbage collector, which needs the least memory beside the heap and suits a single-threaded test run.
A local run of the whole nightly command checks the limits: no mutant may end in MEMORY_ERROR, since one such mutant turns the gate red.
In that run a minion used about 300 to 400 MiB of resident memory and the main process about 530 MiB.
The change is merged before its local run has finished, so that the next nightly build already runs with the limits. The result of the local run follows as a comment on this pull request.