MeowIce Flags: JVM startup flags for Minecraft servers on GraalVM

A repository that is a single README and nothing else

The repository contains exactly one file, the README, and no code, no scripts and no configuration files. That tells you everything about how the flags are meant to be used: they are a piece of text that a server administrator copies into a start command. The description calls the project the most high-performance Java flags to start modern Minecraft servers with GraalVM, and the README frames the same idea as a high-performance JVM Startup Flag set designed to work with modern Minecraft and Java versions. The project is credited in two places outside its own repository, which is how most people will encounter it. The flags are available on Docker Minecraft Server, on the Birdflop Flags Generator, and the README says they are coming to flags.sh. That distribution path is the practical reason to care about the project: these are the flags a tooling ecosystem now ships, and the README is the source of truth for them.

Compatibility is narrow and stated up front

The compatibility section is short and specific. The flags are compatible and tested with Java 25 or newer, GraalVM JVM, Linux, Minecraft 1.21 or newer, and x86_64 systems. Every one of those constraints is a hard boundary rather than a suggestion. Java 25 matters because the flags lean on features of recent JVMs, and GraalVM matters because a large part of the tuning is in `jdk.graal` system properties. Linux matters because the memory assumptions are tuned for a Linux deployment, and x86_64 matters because the flag set contains instructions that do not exist on other architectures. The README also notes that with Minecraft having progressed to version 1.21.x and soon Java 26, most of Aikar's flags are obsolete or have been integrated into the JVM itself, which is the argument for the whole project rather than a footnote to it.

ARM64 users have to edit the flag set by hand

One note stands out for anyone not on x86_64:

> On ARM64 systems, you must manually remove these architecture specific args: `-XX:+UseFastStosb -XX:+UseXmmI2D -XX:+UseXmmI2F -XX:+UseXmmLoadAndClearUpper -XX:+UseXmmRegToRegMoveAll -XX:UseAVX=2`.

The README cites a commit in the itzg/docker-minecraft-server repository as the source for that list, which is a reasonable provenance given where most people pick up these flags. The instruction is honest but manual: there is no script in this repository that detects the architecture and strips the right options, so an ARM64 operator has to edit a string of flags by hand and remember to do it again on every update. The list also tells you something about the shape of the G1GC set, which leans hard on x86 vector and floating point intrinsics such as the Xmm conversions and the FMA support.

Two sets, chosen by heap size, and a core count that gates the ZGC one

The flag set ships in two variants and the choice between them is stated in the README as a memory threshold. The G1GC version is for servers below 32GB allocated heap, and is described as recommended for servers allocated below 32GB RAM with basic resource usage, balanced between memory usage and performance. The ZGC version is for servers with 32GB or more of allocated memory and many CPU cores, allowing for minimizing the delay between each GC run with a larger heap size in an intensive environment. The ZGC variant carries a warning that is worth reading before anything else:

> Only use this if you have more than 10 CPU cores; using ZGC on systems with fewer than 8 cores may cause a significant performance impact !

That threshold is unusual to see stated plainly, and it is the single most useful line in the README for someone deciding which string to paste.

The ZGC string uses `-XX:+UseZGC` with `-XX:-ZProactive`, and it sizes the heap through `-XX:SoftMaxHeapSize=$((Memory - 2048))M`, which is a shell arithmetic expression rather than a fixed number, so the flags expect to be interpolated with the memory you have allocated rather than pasted literally. The rest of the string overlaps heavily with the G1GC set, since the code cache sizes, the NUMA setting, the large page settings and the GraalVM properties are the same, and the collector-specific G1 options are simply absent. That shared tail is the more interesting part of the design, because it means switching collectors is not a wholesale change of configuration but a substitution of one group of options for another. The G1GC note, for comparison, says this is the recommended set for servers allocated below 32GB RAM with basic resource usage:

> This is recommended for servers allocated below 32GB RAM with basic resource usage. Balanced between memory usage and performance.

The heap threshold and the core threshold interact, so a large machine with few cores is exactly the case the ZGC warning excludes.

The G1GC set keeps Aikar's tuning and adds GraalVM options

The full G1GC string is long, and here it is in the form the README gives it:

Read it as three layers. The first is the collector and heap shape, with `-XX:+UseG1GC`, a 200 millisecond pause target, `-XX:G1HeapRegionSize=16M`, and the Aikar-derived ratios such as `G1NewSizePercent=28` and `InitiatingHeapOccupancyPercent=20`. The second is code cache and compilation behaviour, with the node limits, the four code cache heap sizes and `AlwaysActAsServerClassMachine`. The third is the GraalVM layer, the `-Djdk.graal.*` properties at the end that turn on priority inlining, vectorization, loop inversion and duplicate detection. The README says the flags integrate the existing Aikar's G1GC performance tuning while using the latest advanced performance tweaks from GraalVM, and that the Aikar tuning still has an effect in some specific cases, which is why it is not thrown away.

Why GraalVM is the argument, and Leaf is the bonus

The README has a section on why GraalVM rather than others, and the reasoning is about the compiler rather than the collector. GraalVM is described as having better JIT performance and more aggressive optimizations compared to the traditional HotSpot C2 found in many JDKs, including OpenJDK and AdoptiumJDK, and the claimed effect is that inlining, loop unrolling, escape analysis and vectorization work better while maintaining lower CPU usage. The second claim is that the GraalVM compiler compiles plugins and server code faster and smarter, adapting to actual usage and environment on the fly. A tip adds that GraalVM allows you to inspect memory usage and trace down problematic plugins using VisualVM, which is a practical advantage for a server admin chasing a plugin leak. Another tip says that pairing the flags with Leaf as server software can get more performance, which is the one place where the project overlaps with a specific server fork.

Where MeowIce Flags is the wrong choice

Three limits are concrete. The first is the platform, since the combination of Java 25, GraalVM, Linux, Minecraft 1.21 and x86_64 leaves out a lot of people, including anyone still on Java 17 or 21, anyone running on ARM hardware, and anyone on Windows. The second is the reproducibility problem. There is no script here, no version file, no tag and no release, so when the README changes, a server that pasted the flags last month and a server pasting them today are running different configurations with nothing recording which is which. The flags are also long enough that a single missing option changes behaviour, and a mistake in a `-XX:` value can stop the server booting. The third is licensing and provenance. The repository metadata reports the licence as unknown and there is no licence file in the tree, so there is nothing to point at when someone asks whether these flags can be redistributed in a hosting panel's default configuration, even though a list of JVM options is not the kind of material that raises the questions a code licence does.

The alternative is a maintained generator, and the difference is who edits the flags

The realistic alternative is to take the flags from a tool that tracks JVM releases rather than from a README, such as the Birdflop Flags Generator that this project is already published on, or the Aikar flags that the README positions itself against. The difference in approach is maintenance rather than content. Aikar flags are the baseline the whole community runs, and the README's case against them is that they were written for the Java 8 era of 2014 to 2018 and that most of them are now obsolete or folded into the JVM, so running them in 2026 is described as almost a placebo effect. A generator updates its recommendations when a new JVM release lands and can present the options that suit a given heap size and core count. MeowIce Flags' advantage is that it is one author's opinion about what a modern server wants, tuned around GraalVM specifically, and its cost is that it only changes when that author edits a README.

Editorial conclusion

MeowIce Flags fits a server admin on a Linux x86_64 box running Java 25 with GraalVM who has a large player base or a heavy plugin count and wants the Aikar-era G1 tuning carried forward with ZGC available for large heaps. It is the wrong tool for an older Java, for ARM64 hardware unless you edit the flags by hand, and the wrong tool for anyone who needs a reproducible or auditable configuration, since the repository contains only a README and no script, no version metadata and no licence file. Before you adopt it, read the compatibility list against your own Java version, and copy the flags from the README rather than from a third-party generator.

Frequently asked questions

Official sources

1. Issues
2. MeowIce/meowice-flags on GitHub
3. README