1.8 KiB
PR#135: PIT Minions without a Heap Limit
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
PR#134 limited each PIT minion to 512 MiB of heap.
It was merged before its local check had finished, so that the nightly build would already run with it.
The check then failed: a full local run of the nightly command ended 8 mutants in MEMORY_ERROR, and 7 methods became INCONCLUSIVE.
werkcrappit refuses an inconclusive method, so the nightly gate would turn red for that alone.
The affected methods are mostly covered by Spring tests (UiController, Watcher).
A minion runs many tests one after the other, and Spring keeps their application contexts cached, so its heap need grows over its life.
| JVM in the local run | Limit | Highest resident memory |
|---|---|---|
| PIT main process | 768 MiB heap | 659 MiB |
| PIT minion | 512 MiB heap | 1050 MiB |
Non-Goals
- No new minion limit yet: a limit that fits needs its own measured run, e.g. with a smaller Spring context cache. That run takes more than an hour, and the next nightly build starts sooner.
The Solution
- The minions lose
-Xmx512mand keep only-XX:+UseSerialGC; their heap limit is the JVM default again, a quarter of the RAM, as before PR#134. - The main process keeps
-Xmx768m: it stayed below 700 MiB and had no memory error.
Follow-up PRs
- A limit for the minions that fits, measured with a full run, possibly together with
spring.test.context.cache.maxSizefor the minions.