HeapHammer

Deterministic Minecraft server stress testing and retained-memory regression detection.

HeapHammer

Memory leaks in a big modpack usually don't show up until a server has been running for a day or two under real player load, like someone flying around on an Elytra, a mob farm running non-stop, machines cycling. By the time the crash happens, you've lost the context that would tell you which mod caused it.

HeapHammer runs that same kind of load on demand and compresses it into about two minutes. It loads chunks, spawns and removes entities, and places and breaks block entities, using the same code paths a real player would trigger, then checks whether memory came back down afterward or kept climbing. It gives you a straight answer: PASS (memory recovered), PASS (plateau) (it settled after an initial cache warm-up), or SUSPICIOUS (memory keeps growing, cycle after cycle - that's a leak).

It's server-side only. You don't need to tell your players to install anything.

What it's built to catch

  • Minimap and land-claim mods that keep chunk data after the chunk unloads
  • Entity-tracking or damage-indicator mods that don't clean up after mobs despawn
  • Tech mods whose machines don't unregister properly when broken
  • The kind of leak that only appears when two specific mods are running together, which is usually the hardest to find

You don't need to configure anything mod-specific. It works against whatever's installed because it's exercising the vanilla server, not the mods directly.

Safe to run on a live server

It only touches its own test chunks and entities — never a player's builds or the world spawn. Everything it does is budgeted to a maximum of 15ms per tick, so it won't cause lag or trip your watchdog. If you want to stop a test early, /hh stop or /hh cleanup clears everything immediately.

Using it - Quick Start

Drop the jar in your server's mods folder, then from the console or in-game as an operator:

/hh doctor
/hh run chunks --iterations=5 --batch=10 --radius=8 --strategy=spiral
/hh report show last
 

If you're chasing down a leak after adding a new mod, run it before and after, then compare the two with /hh report diff, and it'll show you which one changed the numbers.

Other commands: hh status, hh stop, hh cleanup, hh replay <run-id>, hh diagnostics histogram, hh diagnostics heapdump. Everything requires operator level 2 or higher, and it also works with Fabric Permissions API or LuckPerms if you're using either.

It's been tested with 86 automated tests, and against a real dedicated server: a clean install measured 0.75 MB of retained memory per cycle (no false alarm), while a version with a deliberately seeded leak measured 10.56 MB per cycle. It also caught a leak that only showed up when two specific mods were run together — the kind that's easy to miss by testing mods one at a time.

Full Command List

Command Description
hh doctor Server readiness, chunk/ticket health
hh run chunks / entities / blockentities Run a stress workload
hh status / hh stop / hh cleanup Monitor and halt
hh report show <id|last> Retention slope, R², verdict
hh report diff <runA> <runB> Compare two runs to pinpoint a regression
hh replay <run-id> Replay the exact operation sequence
hh diagnostics histogram / heapdump JVM class histogram or .hprof dump

Supported versions

Forge: 1.7.10, 1.12.2. Fabric: 1.16.5, 1.18.2, 1.19.2, 1.20.1, 1.21.1, 1.21.4. NeoForge: 1.21.1.

License: LGPL-3.0.

The HeapHammer Team

profile avatar
Owner
  • 1
    Projects
  • 173
    Downloads

Making mods to fix issues