Aggressive chunk unloading to keep TPS stable during exploration.
MemorySweeper forces distant chunks to unload immediately instead of waiting for vanilla's slow ticket-expiry mechanism. Designed for large modpacks where exploration causes chunk counts to spiral out of control, degrading server TPS.
Note: MemorySweeper reduces loaded chunk count and GC pressure, which helps maintain stable TPS and MSPT. It does not handle returning freed heap memory to the OS — that requires JVM-level tuning (-XX flags).
Vanilla unloads ~4 chunks per second. When you explore, 20-30 new chunks load per second — the gap causes chunk counts to rise indefinitely, increasing GC pressure and dragging down TPS.
MemorySweeper hooks into ChunkMap.processUnloads() and:
- Scans all loaded chunks every 0.5 seconds
- Identifies chunks beyond view distance + 1
- Pushes them directly into the pending-unload queue (bypassing ticket delays)
- Raises the per-tick unload limit from 200 to 800
Exploration without MemorySweeper: 4,000-5,500 chunks loaded
Exploration with MemorySweeper: 2,200-2,800 chunks loaded (40-50% reduction)
- MSPT overhead: <1ms per scan
- Reduced GC pressure, stable TPS
- Compatible with all chunk-related mods (FTB Chunks, etc.)
- Download the
.jarfrom Releases or CurseForge / Modrinth - Place in
mods/folder - Requires Minecraft 1.20.1 + Forge 47.x
No dependencies. Works on both client (single player) and dedicated server.
No configuration needed. Works out of the box. If you want to tune:
| Parameter | Default | What it does |
|---|---|---|
| Scan interval | 0.5s | How often to scan for distant chunks |
| Unload threshold | view distance + 1 | How close a chunk must be to stay loaded |
| Batch size | 128 | Max chunks added to unload queue per scan |
| Unload limit | 200→800 | Per-tick processing limit inside processUnloads |
Tested and safe with:
- FTB Chunks, FTB Quests
- Applied Energistics 2
- Mekanism
- Industrial Upgrade
- JEI, Jade, Spark
./gradlew buildOutput: build/libs/MemorySweeper-<version>.jar
MIT — see LICENSE