Argumentos JVM para Minecraft: qué parámetros funcionan y cuáles son mitos

El problema: la proliferación de listas de argumentos obsoletos para Java

En foros, vídeos y servidores de Discord circulan listas de argumentos JVM que prometen más FPS o menos tirones en Minecraft. Algunas contienen opciones específicas de versiones antiguas de Java o pensadas para servidores; otras son válidas solo en ciertas versiones. Antes de copiarlas, consulta qué hace cada opción y confirma que la JVM de tu launcher la reconoce.

Una opción no reconocida puede impedir que Java arranque; otra puede no producir el efecto que esperabas. El resultado de un ajuste depende de la versión de Java, el tamaño del heap, la carga del mundo, los mods y el equipo. Esta página explica conceptos y propone una forma de comparar cambios; no presenta una configuración probada en hardware propio.

La base de todo: Cómo gestiona la memoria la JVM en Minecraft

Para interpretar los argumentos de memoria, distingue el heap Java de otras áreas de memoria que utiliza el proceso:

• El montón de memoria (Java Heap Space): Es el espacio administrado por la JVM donde residen objetos Java vivos, incluidos datos de juego. No equivale al consumo total de memoria del proceso. Los argumentos -Xmx (límite máximo) y -Xms (asignación inicial) controlan estrictamente las dimensiones de este espacio.
• Memoria nativa fuera del montón (Off-Heap / Native Memory): Java no solo consume lo que le asignas en -Xmx. El motor gráfico de Minecraft (LWJGL, OpenGL o Vulkan) y los controladores de vídeo reservan memoria nativa adicional por fuera del montón. Por tanto, el uso total de memoria del proceso puede superar el límite de -Xmx. Reserva margen para Windows, el launcher, controladores gráficos y otras aplicaciones; el efecto de paginación depende del uso real del sistema.
• El recolector de basura (Garbage Collector): A medida que juegas, destruyes bloques o te mueves por el mundo, miles de objetos dejan de ser útiles en la memoria. El recolector de basura es el subproceso encargado de identificar estos datos obsoletos y eliminarlos para liberar espacio. Algunas fases de recolección pueden pausar temporalmente hilos de la aplicación; duración y frecuencia dependen de la JVM y de la carga. No hay una pausa fija deducible únicamente del valor de -Xmx.

Los tres grandes mitos de los argumentos JVM desmentidos

Mito 1: "Cuanta más memoria RAM asignes en los argumentos, más rápido irá el juego"

Un -Xmx más alto permite que el heap crezca, pero no acelera por sí solo el juego. Si el heap asignado consume demasiada memoria física, otros procesos y la memoria nativa de Java pueden quedarse sin margen; por otro lado, un valor bajo puede ser insuficiente para un modpack concreto. El recolector puede detener brevemente los hilos de la aplicación en algunas fases, pero el efecto depende de la versión de Java y del patrón de asignaciones. Ajusta el límite con las observaciones del perfil, no con una cantidad universal.

Mito 2: "Los argumentos de Aikar para servidores deben usarse en el cliente"

Los conjuntos de argumentos publicados para Paper se diseñan para ciertos perfiles de servidor y cargas; no deben trasladarse automáticamente al cliente. Lee la documentación que acompaña la configuración y confirma versión de Java, uso de memoria y objetivos previstos antes de probar una opción.

Mito 3: "Activar -XX:+UseConcMarkSweepGC mejora los FPS"

CMS fue eliminado de OpenJDK en Java 14, así que una JVM moderna puede rechazar esa opción. Si aparece Unrecognized VM option, consulta el mensaje completo, confirma qué Java ejecuta realmente el launcher y retira únicamente la opción incompatible. Una bandera antigua puede impedir el arranque, pero eso no implica que todas las listas heredadas contengan opciones inválidas.

Protocolo para revisar argumentos y configurarlos con cuidado

Paso 1: Ajustar el límite del heap (-Xmx)

-Xmx establece el tamaño máximo del heap; -Xms establece su tamaño inicial. No es obligatorio hacerlos iguales: reserva el margen necesario para Windows, el launcher, los gráficos y otras aplicaciones. Empieza por el valor del perfil o modpack y cambia el máximo en incrementos moderados únicamente si los registros muestran falta de heap.

-Xmx4G

No asignes un valor solo por la cantidad total de RAM del equipo o por el número de mods. Empieza con lo que recomienda el launcher o el autor del modpack, vigila el margen del sistema y aumenta el límite solo si observas falta real de heap. La guía sobre ajuste de memoria describe una prueba gradual.

Paso 2: Utilizar el recolector de basura adecuado según tu versión de Java

En las versiones de Java donde está disponible, G1 es la opción predeterminada habitual; la JVM documenta sus opciones de pausa como objetivos de ajuste y no como una garantía de duración máxima. ZGC está diseñado para pausas bajas, pero no garantiza que Minecraft deje de tener tirones: carga de chunks, drivers, mods y otros recursos también influyen. Revisa la documentación de la versión de Java antes de cambiar el recolector.

En Java 21, Generational ZGC se habilita con las opciones descritas por esa versión; en versiones posteriores las opciones pueden cambiar o quedar obsoletas. No copies -XX:+ZGenerational sin consultar la documentación correspondiente. Empieza con el recolector predeterminado y evalúa un cambio solo si los registros muestran pausas de GC relevantes.

Paso 3: Evalúa opciones avanzadas solo con evidencia

Opciones como -XX:+AlwaysPreTouch cambian el comportamiento de reserva de memoria y pueden afectar el inicio y el uso de recursos. No garantizan eliminar tirones. Déjalas fuera de una configuración general salvo que un diagnóstico específico justifique probarlas.

No añadas opciones de monitorización o memoria como -XX:+PerfDisableSharedMem sin una necesidad identificada: pueden cambiar la disponibilidad de datos para herramientas de diagnóstico y no constituyen por sí mismas una optimización comprobada de FPS.

Opciones específicas de plataforma: revisa -XX:+UseNUMA antes de copiarla

NUMA es una característica de acceso a memoria de ciertas plataformas; -XX:+UseNUMA no activa núcleos de CPU. Su disponibilidad y efecto dependen del sistema operativo, la JVM y el hardware. Para una guía general de cliente, deja que la JVM seleccione el comportamiento predeterminado, salvo que la documentación de tu entorno y una prueba controlada justifiquen otra cosa. Evita fijar -XX:ParallelGCThreads al número de núcleos sin medirlo.

Cómo observar la memoria sin confundir el síntoma con la causa

Para observar el heap durante una prueba de diagnóstico, anota los valores iniciales y repite la misma carga después de cada cambio:

1. Inicia Minecraft y entra a un mundo con tus mods habituales.
2. Presiona la tecla F3 y observa el gráfico de memoria en la esquina superior derecha.
3. Un pico y una bajada del heap pueden formar parte del funcionamiento normal del recolector; el gráfico F3 por sí solo no identifica la causa de un tirón ni confirma una fuga.
4. Observa también la memoria física disponible del sistema y los registros de GC, si los estás recopilando. No hay un umbral único de memoria libre que garantice fluidez en todos los equipos.

Cómo evaluar un argumento sin asumir que optimiza

1. Registra Java, Minecraft, cargador, mods, valor de -Xmx y ajustes del mundo.
2. Elige una ruta corta y repetible; deja que cargue el escenario y anota el síntoma y los registros relevantes.
3. Cambia una sola opción, repite varias veces en la misma instancia y compara pausas o mediciones pertinentes.
4. Si no hay diferencia consistente o aparecen errores, vuelve al valor anterior. No cambies a la vez heap, recolector y mods.

El lanzador puede agregar argumentos propios. Antes de editar la línea completa, revisa qué opciones están activas y conserva una copia para poder revertirla.

Conclusión

Usa argumentos JVM solo cuando entiendas su propósito y hayas comprobado que corresponden a la versión de Java de tu instancia. El valor inicial del launcher suele ser el mejor punto de partida; cualquier ajuste debe compararse en condiciones repetibles y revertirse si no aporta una diferencia consistente.