Quels arguments Java pour un serveur Minecraft moddé

D’abord la bonne version de Java

Aucun flag ne sauvera un serveur lancé avec le mauvais Java : c’est le premier point à vérifier, et la contrainte vient de la version de Minecraft, pas du modpack. Installez de préférence les builds Temurin d’Adoptium, gratuits et sans piège de licence, et attention dans les deux sens : un pack 1.12.2 refuse Java 17 aussi sûrement qu’un pack 1.20.5 refuse Java 8.

• Minecraft 1.7.10 à 1.16.5 (RLCraft, GTNH, Create: Above and Beyond…) : Java 8 — GregTech: New Horizons fait exception, sa 1.7.10 modernisée tourne en Java 17 à 25.
• Minecraft 1.17 : Java 16, version de transition vite abandonnée.
• Minecraft 1.18 à 1.20.4 (Create Astral, BMC4, Prominence II…) : Java 17.
• Minecraft 1.20.5 à 1.21.x (All The Mods 10, BMC5…) : Java 21.
• Minecraft 26.1 et au-delà (le nouveau schéma de versions de 2026) : Java 25.

Les flags d’Aikar, la base qui marche

Aikar, développeur de l’écosystème Paper, a publié en 2018 un jeu d’arguments qui règle le garbage collector G1 pour le profil mémoire très particulier de Minecraft : énormément d’objets à durée de vie ultra-courte (un tick les crée, le suivant les jette). Sans réglage, le GC laisse s’accumuler ce travail puis fait de grosses pauses — les fameux freezes périodiques où le TPS décroche. Les flags d’Aikar forcent des collectes petites et fréquentes qui passent inaperçues. Conçus pour Paper, ils s’appliquent tout aussi bien à un serveur Forge, NeoForge ou Fabric : le comportement mémoire d’un serveur moddé est le même, en plus gourmand.

La ligne complète pour un serveur avec 10 Go, à adapter à votre allocation : java -Xms10G -Xmx10G -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 -jar server.jar nogui

Les pièces maîtresses : UseG1GC active le collecteur G1 ; G1NewSizePercent et G1MaxNewSizePercent réservent 30 à 40 % de la heap à la jeune génération, là où vivent et meurent les objets d’un tick ; MaxGCPauseMillis=200 borne chaque pause sous la durée de quatre ticks ; AlwaysPreTouch fait réserver toute la RAM au démarrage plutôt qu’au fil de l’eau ; PerfDisableSharedMem évite des à-coups d’écriture disque ; MaxTenuringThreshold=1 jette vite ce qui doit l’être au lieu de le recopier de collecte en collecte. À partir de 12 Go alloués, Aikar recommande une variante : G1NewSizePercent=40, G1MaxNewSizePercent=50, G1HeapRegionSize=16M, G1ReservePercent=15 et InitiatingHeapOccupancyPercent=20.

-Xms = -Xmx : pourquoi cette règle

-Xmx fixe le plafond de mémoire de la JVM, -Xms sa taille de départ. Sur un serveur dédié au jeu, mettez les deux à la même valeur : la mémoire que vous n’allouez pas à Minecraft ne sert à rien d’autre, et une heap de taille fixe évite à G1 de perdre du temps à grandir et rétrécir — combiné à AlwaysPreTouch, tout est réservé proprement dès le démarrage. Seule exception : une machine partagée où d’autres services ont réellement besoin de cette mémoire.

Gardez aussi une marge pour le système : la JVM consomme au-delà de la heap (métadonnées, threads, mémoire native des mods). Sur une machine de 16 Go, allouez 10 à 12 Go, pas 15 — un serveur qui pousse le système dans le swap devient injouable bien plus sûrement qu’un serveur un peu juste en heap.

G1GC ou ZGC générationnel : qui a besoin de ZGC ?

Depuis Java 21, ZGC existe en mode générationnel — et sur les JDK récents, activer ZGC (-XX:+UseZGC) vous donne ce mode d’office. Sa promesse : des pauses inférieures à la milliseconde quelle que soit la taille de la heap, là où G1, même bien réglé, laisse passer des pauses de quelques dizaines de millisecondes sur les très grosses allocations. Le prix : environ 10 à 15 % de CPU en plus consacré au GC, et un léger surcoût mémoire.

La conclusion pratique est simple. Jusqu’à 12 Go d’allocation — la quasi-totalité des serveurs moddés —, G1 avec les flags d’Aikar reste le meilleur compromis : les pauses sont déjà imperceptibles et le CPU économisé revient aux ticks du serveur. Le ZGC générationnel prend l’avantage sur les configurations atypiques : 16, 24, 32 Go de heap pour un gros serveur public sur un pack lourd, avec des cœurs CPU en réserve. Si c’est votre cas, remplacez tous les flags G1 par -XX:+UseZGC (en gardant Xms=Xmx et AlwaysPreTouch) et comparez le résultat sous charge réelle avec spark — c’est le verdict qui compte, pas la théorie.

Les pièges classiques

• Trop de RAM : au-delà du nécessaire, chaque collecte brasse une heap plus grosse pour rien. Passer de 10 à 20 Go n’accélère pas un serveur qui n’en utilise que 8 — cela rallonge le travail du GC.
• Les flags magiques copiés sans comprendre : les listes exotiques trouvées sur les forums cumulent souvent des arguments obsolètes, contradictoires, voire ignorés par les JVM modernes. Une base saine et mesurée bat un empilement mystique.
• Les flags client sur un serveur : les réglages pensés pour améliorer les FPS d’un client moddé n’ont rien à faire dans un script serveur, et réciproquement.
• GraalVM en remède miracle : son compilateur JIT peut apporter un gain modeste sur certains packs, mais c’est une optimisation marginale à tester en dernier — après la version de Java correcte, les flags GC et le nettoyage des vraies sources de lag.
• Changer trois choses à la fois : modifiez un paramètre, mesurez une journée, concluez. Sinon vous ne saurez jamais ce qui a agi.

Mesurer avec spark plutôt que croire

Le réflexe qui sépare les serveurs bien administrés des autres : installer spark (Forge, NeoForge, Fabric — gratuit et quasi sans surcoût) et regarder les chiffres avant de toucher aux flags. /spark tps affiche TPS et MSPT (millisecondes par tick), /spark gcmonitor journalise chaque pause du GC en temps réel, /spark profiler produit un rapport interactif qui montre exactement où passe le temps de chaque tick.

La lecture est sans appel : si les pauses GC sont rares et courtes mais que le MSPT dépasse 50 ms, votre problème n’est pas la JVM — c’est une ferme de mobs, une machine moddée ou un chunk surchargé, et c’est le profiler qui le désignera. Les arguments Java éliminent les à-coups de mémoire ; ils n’achètent pas de temps de tick. Réglez les flags une fois, correctement, puis passez votre énergie là où spark pointe.