You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG][1.21.1]Memory leak in VoxelShapeCache.mergeShapeCache (unbounded cache leads to OOM) #473
We are experiencing a severe memory leak on a modded Minecraft server (1.21.1) caused by the mergeShapeCache inside codechicken.lib.raytracer.VoxelShapeCache. The cache uses expireAfterAccess(2, HOURS) but no maximum size or weak reference, causing it to accumulate millions of ImmutableSet<VoxelShape> entries over time. Each entry holds VoxelShape objects which internally contain large double[] arrays (or DoubleArrayList), eventually consuming 90%+ of the heap (14+ GB) and causing server freezes / crashes.
mergeShapeCache never evicts entries as long as they are accessed every 2 hours. In a busy server, many distinct shape sets are constantly created, and the cache grows indefinitely.
Keys (ImmutableSet) strongly reference VoxelShape objects, which in turn hold large primitive arrays. This prevents GC from recovering memory.
The leak is amplified by mods that frequently call VoxelShapeCache.merge() (e.g., raytracing for entity culling, block rendering, or Translocators' pipe rendering).
Suggested fix:
Add a reasonable maximum size and/or use weak references:
privatestaticfinalCache<ImmutableSet<VoxelShape>, VoxelShape> mergeShapeCache =
CacheBuilder.newBuilder()
.maximumSize(5000) // limit number of entries
.expireAfterAccess(1, TimeUnit.HOURS) // shorter expiry
.weakValues() // allow GC to collect values
.build();
Alternatively, at least set .maximumSize(10000) to prevent unbounded growth.
Impact:
Without this fix, servers running any mod that uses CCL's VoxelShapeCache will eventually run out of memory, requiring frequent restarts.
The voxel shape cache should never grow unboundedly, everywhere currently using this should be feeding in cached VoxelShape instances, misses should be infrequent.
Do you have any reproduction steps for this? A known broken modpack? A world download?
I beleve the caches could be reworked to set limits or weak values, or with some better profiling removed alltogether, its likely the merge cache isn't saving much time/memory (compared to the bb/cuboid -> shape cache). However, whatever is calling the merge api and cache missing should also be fixed first.
Also, I'm concerned at the potential use of AI in your report. This issue has been filed on the Translocators repo not CodeChickenLib. You also mention that the leak is amplified by raytracing for entity culling, block rendering, or Translocators' pipe rendering, entity culling does not perform ray tracing, and Translocators does not contain any pipes. Using AI to analyse your heapdump is reasonable, however, please be aware it can hallucinate issues.
After I disabled Translocators and CodeChickenLib, the abnormal memory growth returned to normal.However, my production line may have stopped working due to the removal of Translocators, so the real issue might still be hidden.
I'm not sure about the exact steps to reproduce the memory growth. Perhaps it's due to using a large number of fluid translocators and tanks to replace pipes. Even when I just let the game run idle after logging in, memory consumption increases rapidly. According to spark's memory report, I observed that the number of double[] instances kept growing until it reached 70 million. After I removed a large number of translocators, the memory growth rate decreased significantly. However, through spark I can still see that the above growth process is still happening.
Activity
covers1624 commentedon Apr 13, 2026
The voxel shape cache should never grow unboundedly, everywhere currently using this should be feeding in cached VoxelShape instances, misses should be infrequent.
Do you have any reproduction steps for this? A known broken modpack? A world download?
I beleve the caches could be reworked to set limits or weak values, or with some better profiling removed alltogether, its likely the merge cache isn't saving much time/memory (compared to the bb/cuboid -> shape cache). However, whatever is calling the merge api and cache missing should also be fixed first.
Also, I'm concerned at the potential use of AI in your report. This issue has been filed on the Translocators repo not CodeChickenLib. You also mention that the leak is amplified by
raytracing for entity culling, block rendering, or Translocators' pipe rendering, entity culling does not perform ray tracing, and Translocators does not contain any pipes. Using AI to analyse your heapdump is reasonable, however, please be aware it can hallucinate issues.1341254443 commentedon Apr 13, 2026
After I disabled Translocators and CodeChickenLib, the abnormal memory growth returned to normal.However, my production line may have stopped working due to the removal of Translocators, so the real issue might still be hidden.
I'm not sure about the exact steps to reproduce the memory growth. Perhaps it's due to using a large number of fluid translocators and tanks to replace pipes. Even when I just let the game run idle after logging in, memory consumption increases rapidly. According to spark's memory report, I observed that the number of double[] instances kept growing until it reached 70 million. After I removed a large number of translocators, the memory growth rate decreased significantly. However, through spark I can still see that the above growth process is still happening.
Modpack: Cook in Skyland Elegant Feast (0.6.0) – https://www.curseforge.com/minecraft/modpacks/cook-in-skyland-elegant-feast
Extra mods I added: Spark (1.10.124), Tom's Simple Storage (1.21-2.3.0)
I have also removed the
Distant Horizonsmod.World save: https://u.pcloud.link/publink/show?code=XZw1E65ZwXxhJFbpNUkMOLasY9LINLnzbfOX
(Unfortunately, I no longer have the old world save where I was using a large number of transposers.)
(Apologies if my use of AI caused any confusion – my computer skills are limited, so I rely on AI for help.)