Files
werkator/docs/prs/2026-10-10-PR#135-pit-minions-without-heap-limit.md
claude-code 6097e550ec
werkator build succeeded after 02:41
werkator/deploy build succeeded after 00:08
werkator/mutation build failed after 53:42
PIT minions without a heap limit (v1.38.3) (#135)
Co-authored-by: claude-code <claude-code@javagil.de>
2026-10-10 00:08:20 +02:00

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 -Xmx512m and 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.maxSize for the minions.