Quick answer: run ATM10 on Java 21, pick 12GB, 16GB or 32GB of server RAM by player count, keep the G1GC flags the pack ships in user_jvm_args.txt but raise its -Xmx8G to fit your plan, try Generational ZGC if stutter is your problem, and raise the NeoForge read timeout if players get dropped while the pack loads.
All The Mods 10 is one of the heaviest modpacks you can run on a Minecraft server. With around 500 mods, Java's memory management becomes the single biggest factor in whether your server runs smoothly or becomes a slideshow every 30 seconds.
The default JVM arguments that most hosting panels set are generic. They work for vanilla Minecraft, but ATM10 needs specific tuning, and the -Xmx12G -Xms12G line that every forum thread repeats leaves a lot on the table. Below are the flags the pack's own server files ship, the Generational ZGC option from the official ATM guide, when to pick each one, and the config that has to go with them.
This page is only about JVM arguments and the settings that sit next to them. For hardware and RAM sizing, see ATM10 server requirements. For a quick per-workload number, use the ATM10 RAM calculator. For running it on your own machine, see ATM10 PC specs.
Why ATM10 Needs Different Flags from Other Modpacks
ATM10 runs on NeoForge with around 500 mods active at once. At startup the JVM is initialising thousands of classes. Once the world is running, every mod that processes items, updates machines or renders effects produces garbage at a rate that vanilla flags were never written for.
That is why copying a vanilla flag set across rarely helps. The problem is not that the collector is bad, it is that the allocation rate is far higher than those flags were tuned for, and the pauses land exactly when a player is flying through ungenerated chunks or a mob farm has just ticked.
What Java Version Does ATM10 Need
Java 21. NeoForge builds for ATM10 target it, and it is also what unlocks the collector work described below, including Generational ZGC. The pack's official start script checks this and stops with an error if Java is missing or older than 21. Check what your panel is actually launching with before you spend an evening tuning flags, since a panel can be set to an older installed runtime. If you need the full walkthrough, see the ATM10 Java version guide.
Generational ZGC Flags for ATM10
The official ATM guide offers this ZGC line for Java 21 servers with a fast CPU (4 or more cores) and plenty of RAM:
-Xms8G -Xmx12G
-XX:+UseZGC
-XX:+ZGenerational
-XX:SoftMaxHeapSize=10g
-XX:+DisableExplicitGC
-XX:+AlwaysPreTouch
-XX:+PerfDisableSharedMem
-XX:+UseDynamicNumberOfGCThreads
These lines replace the G1 lines in user_jvm_args.txt, so do not keep both sets. The memory numbers fit a 16GB plan. On a 12GB plan, bring -Xmx and SoftMaxHeapSize down so the heap leaves room for the rest of the process (see the RAM section below).
What each flag is doing:
-XX:+UseZGC -XX:+ZGenerational turns on ZGC in generational mode, which on Java 21 you have to ask for explicitly. The goal is shorter freezes during chunk generation and heavy mob spawning.
-XX:SoftMaxHeapSize=10g asks ZGC to try to keep the heap under 10GB and only grow toward the -Xmx ceiling when it has to.
-XX:+AlwaysPreTouch makes Java map all of its allocated memory at startup rather than lazily. Boot gets slower, and the memory page fault stutters that otherwise show up mid session go away.
-XX:+DisableExplicitGC stops mods calling System.gc() themselves, which would force a full collection at the worst possible moment.
-XX:+PerfDisableSharedMem turns off the JVM's shared memory performance counters, cutting a small amount of OS level interference.
-XX:+UseDynamicNumberOfGCThreads lets the JVM pick how many GC threads to use based on the work, up to its maximum.
If players time out while joining, add the read timeout flag covered further down.
The G1GC Flags ATM10 Ships With
If you would rather stay on G1GC, you already have a tuned set. ATM10's official server files ship these flags in user_jvm_args.txt:
-Xms4G -Xmx8G -XX:+UseG1GC -XX:+ParallelRefProcEnabled
-XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions
-XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:G1NewSizePercent=30
-XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M
-XX:G1ReservePercent=20 -XX:G1HeapWastePercent=5
-XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15
-XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5
-XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1
The one line to change is -Xmx8G. That is the pack's default whatever machine it runs on, so raise it to fit your plan (see the RAM section below).
-XX:MaxGCPauseMillis=200 tells G1GC to target collection pauses under 200 milliseconds. It is a target rather than a promise, but it steers G1 away from the long freezes that wreck TPS during heavy automation.
-XX:G1NewSizePercent=30 and -XX:G1MaxNewSizePercent=40 give more of the heap to the young generation, where short lived objects live. ATM10 mods create enormous numbers of these, so a larger young generation means fewer expensive full GC events.
-XX:G1HeapRegionSize=8M raises the region size, which suits the large allocations modded Minecraft produces constantly.
The AlwaysPreTouch, DisableExplicitGC and PerfDisableSharedMem flags do the same job here as they do in the ZGC set. If your players time out while joining, add the read timeout flag from further down.
ZGC vs G1GC for ATM10: Which One Should You Use
Treat it as a trade, not a winner. G1GC is what the pack ships and the safer default. Generational ZGC is designed around short pauses, and the ATM guide only suggests it for fast CPUs with 4 or more cores and plenty of RAM.
The practical rule:
- Your average TPS is fine but the server hitches. Try ZGC in generational mode. Short pauses are what players actually feel.
- Your average TPS is the problem and it is low across the board. Stay on the shipped G1GC set, and check whether the real limit is CPU or RAM rather than the collector.
- You are tight on RAM. Stay on G1GC. The ATM guide pitches ZGC at servers with RAM to spare, and starving the heap to make room for it undoes the benefit.
Whichever you pick, change one thing at a time and measure. Running ZGC flags and G1GC flags together does not work, since the collector selection flags conflict.
How Much RAM to Allocate: -Xms and -Xmx
Start from the server's RAM, then set the heap inside it. Size by player count:
| Players | Server RAM | Space-Node plan |
|---|---|---|
| 1 to 5 | 12GB | MC Special 1 |
| 5 to 15 | 16GB | MC Special 3 |
| 15+ | 32GB | MC Special 4 |
12GB is where we recommend starting, even for a small group. The official server files already give Java an 8GB heap, and Java needs memory on top of the heap. Past five players you want headroom for chunk loading, and past fifteen you are sizing for everyone being active in different dimensions at the same time rather than for an average. On our All The Mods 10 server hosting those plans cost €10.80, €14.40 and €29.99 a month on Standard, or €21.99, €27.99 and €56.99 on Premium, at Netherlands, Germany and Poland prices.
The pack's user_jvm_args.txt ships with:
-Xms4G -Xmx8G
That caps the heap at 8GB whatever server you run it on, so raise -Xmx to fit your plan. You can set -Xms to the same value so Java is not resizing the heap as it goes.
Never set -Xmx higher than your actual available RAM minus 2GB, which the OS and JVM overhead need. Allocating everything is one of the fastest ways to turn a stuttering server into a crashing one.
Fixing ATM10 Players Timing Out While the Pack Loads
-Dneoforge.readTimeout=180
A pack this size can take longer to hand over its mod list and registry data than NeoForge's default read timeout of 30 seconds allows. When that happens the client disconnects part way through joining, usually with a timeout message and no crash report, and it looks like a network fault when it is not.
Raising it to 180 seconds gives the handshake room to finish. This matters most on first join, after a pack update when registries have changed, and for players on slower connections. If you see people repeatedly failing to get past the loading screen while the server itself is healthy, set this before you go looking anywhere else.
Older guides list -Dfml.readTimeout and -Dfml.loginTimeout instead. Those are old Forge property names and NeoForge 1.21.1 reads neither of them. -Dneoforge.readTimeout is the one that works, and NeoForge 1.21.1 has no login timeout property to replace the other, so remove both old flags if they are in your start line.
Where to Put These Flags
ATM10's official startserver.sh launches the server with this line:
java @user_jvm_args.txt @libraries/net/neoforged/neoforge/21.1.265/unix_args.txt nogui
So the -Xms, -Xmx, -XX and -D flags belong in user_jvm_args.txt. The version in the libraries path is the NeoForge version of your pack, 21.1.265 for ATM10 8.4. Anything after the NeoForge args file, like nogui, is passed to the server rather than the JVM. If you paste flags there, they never reach Java, which is why a flag set can look applied and change nothing.
On a Space-Node server you can edit user_jvm_args.txt in the file manager, and the panel's Startup tab also has a JVM arguments field. Whichever route you use, make sure only one -Xmx ends up on the line that starts the server.
server.properties Settings That Matter for ATM10
JVM flags are only half of it. If there is no server.properties yet, ATM10's start script writes one with these values (plus allow-flight=true):
view-distance=8
simulation-distance=5
max-tick-time=180000
Keep them. Lowering simulation distance is one of the biggest TPS wins on a heavily modded server, and the pack already starts you at 5. Raise it only if the server has TPS to spare.
Keep view distance at 8 or lower. ATM10's worldgen is expensive and loading 10+ chunks around every player will tank TPS.
max-tick-time=180000 gives the server three minutes before it declares a tick hung, which stops it killing itself during heavy world generation or initial loading.
One line worth adding yourself:
max-chained-neighbor-updates=1000
max-chained-neighbor-updates=1000 caps how far a single block update cascade can propagate, which keeps one badly built contraption from stalling a tick. There is more of this in the ATM10 server config guide.
Testing Your Configuration
After changing flags, measure with spark, which ships with ATM10, rather than guessing:
/spark tps
/spark profiler start --timeout 300
NeoForge's built-in /neoforge tps also shows TPS and milliseconds per tick for each loaded dimension.
Run the profiler for five minutes of normal gameplay and read the results. Regular long GC pauses mean the heap is too small. TPS that keeps dropping during automation means you are short on CPU or RAM, and no flag set fixes that. At that point you need a bigger plan, and our ATM10 server hosting page lists the 12GB, 16GB and 32GB options.
The Hardware Underneath the Flags
Flags can only optimise what the hardware gives them, and ATM10's mod loading leans hard on clock speed. On Space-Node, Premium plans in the Netherlands, Germany, Poland and Canada run on the Ryzen 9 9950X with DDR5, Standard plans in the Netherlands, Germany and Poland on an AMD EPYC 7443 with DDR4, Standard in Canada and India on Ryzen 9 3900X-class CPUs with DDR4, our USA locations in California and Virginia on the Ryzen 9 7950X3D with DDR5, and Singapore and Australia on the Ryzen 9 5950X. CPU is shared on every plan, in every region.
If you have applied these flags and TPS is still bad, the configuration probably is not the problem. The server is short on CPU time, and a spark profile shows which mods or machines are using it.
ATM10 Requirements and Lag Guides
If you are still choosing server size, start with ATM10 server requirements and the ATM10 RAM calculator. If your server already runs but TPS drops, use ATM10 lag fix and optimization. For flag theory that applies beyond this pack, see Aikar flags explained.
JVM flags cannot fix a crash that happens outside Java. If your game dies with no crash report, read exit code -1073740791 explained.