> ## Content Index > Fetch the complete content index at: https://dedicatedmc.io/blog/llms.txt > Use this file to discover other available public pages before exploring further. # Aikar's flags and JVM tuning for Minecraft - URL: https://dedicatedmc.io/blog/aikars-flags-jvm-tuning/ - Published: 2026-07-05T10:00:00.000Z - Updated: 2026-10-30T12:20:39.000Z - Description: What Aikar's flags actually do, why garbage collection matters for TPS, and how to size the heap sensibly when tuning a Minecraft server's JVM. - Author: Mark E - Tags: Guide, Minecraft, Performance If you have run a Minecraft server for any length of time, someone has told you to use Aikar's flags. They are the most widely shared piece of JVM tuning in the community, and for good reason: they work. This post explains what they actually do, why the JVM side of a Minecraft server matters, and where the sensible limits of tuning are. Minecraft's server runs on the Java Virtual Machine, and the JVM manages memory for you. That convenience comes with a cost, and understanding it is most of what JVM tuning is about. ## Why garbage collection matters for TPS Java does not make you free memory by hand. Instead the JVM periodically pauses the program, works out which objects are no longer in use, and clears them. That pause is garbage collection, or GC. Here is why it matters for a game server. The server runs a tick loop, aiming for 20 ticks per second, which is 50 milliseconds per tick (MSPT). If the JVM stops the world to collect garbage for 40 milliseconds, that is 40 milliseconds your tick thread was not running. A run of long pauses shows up as a TPS drop, and every player feels it at the same time. Short, predictable pauses are invisible. Long, unpredictable ones are the whole problem. So JVM tuning for Minecraft is mostly about one goal: keep GC pauses short and consistent, even when the server is busy. For the wider picture of what else makes a server stutter, see [what causes Minecraft server lag](https://dedicatedmc.io/blog/what-causes-minecraft-server-lag). ## What Aikar's flags actually are Aikar's flags are a tuned configuration for G1GC, the garbage collector that ships as the default in modern Java. Out of the box, G1GC is set up to be reasonable for a broad range of programs. Aikar's flags retune it for the way a Minecraft server allocates memory, which is a steady churn of short-lived objects every tick. The configuration does a few things, described in plain terms rather than as a magic string to paste: - It tells G1GC to do more, smaller collections rather than fewer, larger ones, trading a little throughput for much shorter pauses. Shorter pauses are what a tick loop wants. - It sizes the internal regions and the young generation for Minecraft's allocation pattern, so the collector spends less effort chasing the server's constant object churn. - It starts collecting earlier, before the heap is under pressure, so the server avoids the long emergency collection that happens when memory fills up suddenly. The exact values have been refined over years of real use. We would rather point you at the reasoning than reprint the whole string, but the load-bearing G1GC values in the current published set are worth naming: a pause target of `MaxGCPauseMillis=200`, a young generation held between `G1NewSizePercent=30` and `G1MaxNewSizePercent=40`, `G1HeapRegionSize=8M`, `G1ReservePercent=20`, and early collection via `InitiatingHeapOccupancyPercent=15` with `G1MixedGCCountTarget=4`. On heaps of 12GB or more, Aikar's guide raises the young-generation bounds to 40 and 50, sets `G1HeapRegionSize=16M`, and drops `G1ReservePercent` to 15 and `InitiatingHeapOccupancyPercent` to 20\. Verify against the current published flags before you paste them. ## Set Xms equal to Xmx One piece of advice sits slightly apart from the rest, and it is worth calling out on its own: set your minimum heap size (Xms) equal to your maximum heap size (Xmx). The instinct is to set a low minimum so the server "only uses what it needs". In practice that makes the JVM grow and shrink the heap while the game is running, and each resize is work the server could have skipped. Pinning both values to the same number hands the JVM its full heap up front. For a long-running server that will use the memory anyway, there is no downside, and it removes a source of avoidable pauses. ## Bigger heaps are not automatically better This is the point people most often get wrong. Once you are tuning flags, it is tempting to also throw more heap at the problem. More RAM, surely, means more headroom. Up to a point, yes. Below that point you are giving the server room it genuinely needs. Past it, a larger heap mostly gives the collector more to scan on a full collection, which lengthens the worst-case pause. You end up with more memory allocated, no more performance, and occasionally a longer stutter than before. The right heap fits the server's real working set with a sensible margin, and no more. We go through sizing by use case in [how much RAM does a Minecraft server need](https://dedicatedmc.io/blog/how-much-ram-minecraft-server). ## A note on huge pages If you want to go a step further, huge pages can help. Normally the operating system maps memory in small 4KB pages, and the CPU keeps a cache of recent mappings. A large JVM heap can overflow that cache, causing extra work every time the server touches memory. Huge pages map memory in much larger blocks, which cuts that overhead and can reduce GC cost. The honest caveat is that huge pages have to be set up properly at the operating system level, and done badly they can add allocation stalls rather than remove them. It is a deliberate setting, not a free switch. On our nodes we tune huge pages for large JVM heaps as part of the OS setup, so on a server with us this is already handled. ## When to look beyond the defaults For most people, a good G1GC configuration and a correctly sized heap is the end of the story. That combination handles the large majority of servers well, and reaching for anything more exotic usually solves a problem you do not have. There are exceptions. Very large heaps, unusual modpacks with strange allocation behaviour, or a server chasing the last few milliseconds of pause time might look at alternative collectors or more specialised tuning. That is a real conversation, but it is a small minority of cases, and most servers never need it. Start with the well-understood defaults, measure your actual GC behaviour, and only go further if the numbers tell you to. If you would rather not tune any of this by hand, we help set sane JVM flags, the right collector and a sensible heap size as part of getting your server running. [Explore Minecraft hosting](https://dedicatedmc.io/minecraft-server-hosting?ref=dedicatedmc.io)