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, servidores de Discord y vídeos de internet es común encontrar supuestas "líneas mágicas de argumentos JVM" que prometen duplicar los cuadros por segundo o eliminar por completo los tirones en Minecraft. La inmensa mayoría de estas cadenas de comandos son combinaciones de parámetros diseñadas hace más de ocho años para Java 8, adaptaciones ciegas de configuraciones pensadas exclusivamente para servidores dedicados de alto tráfico (como las banderas de Aikar para Paper), o directamente inventos que la máquina virtual de Java moderna ignora o rechaza.

Copiar y pegar estas líneas sin comprender la función de cada variable suele provocar dos problemas graves: cierres inmediatos con Código de salida 1 (debido a parámetros eliminados en versiones modernas de Java) o pausas periódicas de congelamiento (lag spikes) provocadas por recolectores de basura mal configurados que detienen el hilo de renderizado del juego. Ajustar correctamente la máquina virtual de Java (JVM) no busca inventar rendimiento donde el hardware no lo permite, sino garantizar que la asignación de memoria y la recolección de residuos se ejecuten de manera predecible y sin interrumpir los fotogramas.

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

Para entender qué argumentos son realmente útiles, es indispensable conocer cómo interactúa Minecraft con la memoria del ordenador:

• El montón de memoria (Java Heap Space): Es el área delimitada de memoria RAM física donde Minecraft almacena los objetos activos: entidades, bloques cargados, texturas y datos de sonido. 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. Si tienes 16 GB de RAM física en tu ordenador y le asignas 14 GB a Minecraft mediante -Xmx14G, la suma de la memoria nativa y los procesos del sistema operativo agotarán la memoria real, obligando a Windows a utilizar el disco como memoria virtual y destruyendo la fluidez del juego.
• 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. Si el recolector está mal configurado o la memoria asignada es excesiva, este proceso detendrá el juego durante medio segundo cada vez que se ejecute una limpieza completa.

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"

Asignar memoria en exceso es perjudicial para la estabilidad. En una instalación Vanilla o con pocos mods ligeros de optimización (como Sodium), Minecraft opera de forma holgada con entre 2 GB y 4 GB de RAM. Si a esa misma instalación le asignas 10 GB o 12 GB, el recolector de basura retrasará sus ciclos de limpieza porque verá abundante espacio disponible. Cuando la memoria finalmente se llene tras media hora de juego, el recolector se verá obligado a limpiar una montaña gigantesca de objetos huérfanos de golpe, congelando la pantalla por completo durante varios segundos (lo que en informática se conoce como pausa Stop-the-World). La regla técnica es asignar solo la cantidad de memoria que el paquete de mods realmente necesita para funcionar sin ahogarse.

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

Las famosas banderas de Aikar fueron diseñadas minuciosamente para servidores dedicados de Minecraft que procesan decenas de jugadores concurrentes, entidades lógicas complejas y transacciones continuas en segundo plano. Un servidor no dibuja gráficos en una pantalla ni sincroniza fotogramas a 60 o 144 Hz. Copiar argumentos agresivos de servidores en el cliente puede desequilibrar los subprocesos de la CPU, priorizando la limpieza de datos por encima del hilo que dibuja la imagen en tu monitor.

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

Este argumento activaba el recolector de basura CMS, un componente clásico de Java 8. Desde el lanzamiento de Java 9, CMS fue declarado obsoleto y en Java 14 fue eliminado definitivamente del código de OpenJDK. Si juegas en versiones modernas de Minecraft (1.18 a 1.21+) que operan sobre Java 17 o Java 21, colocar este argumento provocará que la máquina virtual aborte en el milisegundo cero, impidiendo que el juego llegue a abrirse.

Protocolo técnico: Qué argumentos sí funcionan y cómo configurarlos

Paso 1: Establecer límites simétricos de memoria (-Xms y -Xmx)

Por defecto, muchos lanzadores configuran un -Xms bajo (por ejemplo, 512 MB) y un -Xmx alto (por ejemplo, 4 GB). Esto obliga a la máquina virtual a solicitar continuamente más memoria al sistema operativo en bloques pequeños a medida que el juego arranca, provocando micro-tirones durante la carga inicial.

Al igualar ambos valores, o mantenerlos muy cercanos, obligas a Java a reservar el bloque de memoria de forma estable desde el inicio:

-Xms4G -Xmx4G

Pauta de dimensionamiento según tu equipo:

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

Para Java 17 (Minecraft 1.18 a 1.20.4), el recolector predeterminado más robusto y equilibrado es G1GC. Para garantizar que no genere pausas prolongadas mientras juegas, se añade una directiva que le indica el tiempo máximo que toleras que se detenga el juego para limpiar memoria:

-XX:+UseG1GC -XX:MaxGCPauseMillis=35 -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=20 -XX:G1ReservePercent=15

Si utilizas Minecraft 1.20.5, 1.21 o versiones más recientes ejecutadas bajo Java 21, existe una alternativa de vanguardia: Generational ZGC. Este recolector divide los objetos por antigüedad y ejecuta prácticamente todas sus operaciones de limpieza de forma paralela en segundo plano, reduciendo los tiempos de pausa a menos de un milisegundo:

-XX:+UseZGC -XX:+ZGenerational

Condición técnica estricta: Solo debes utilizar -XX:+ZGenerational si tienes la certeza de que tu entorno está ejecutando Java 21 oficial compilado (verificable mediante java -version en terminal), ya que en Java 17 el modificador generacional de ZGC no existe y provocará un error de sintaxis.

Paso 3: Eliminar fallos de página durante la partida (-XX:+AlwaysPreTouch)

Cuando Windows asigna memoria RAM a una aplicación, inicialmente solo le entrega "direcciones virtuales". La memoria física real se asigna únicamente en el milisegundo exacto en que la aplicación escribe un dato en esa dirección por primera vez. Esto produce pequeños tropiezos de lectura (llamados Page Faults) mientras viajas por el mundo y se cargan nuevos bloques.

Al incluir el argumento:

-XX:+AlwaysPreTouch

Obligas a la JVM a recorrer y reclamar físicamente cada byte de la memoria asignada en el instante en que presionas "Jugar". Esto añade entre uno y dos segundos al tiempo que tarda el lanzador en abrir la ventana, pero a cambio elimina por completo los tirones de asignación de memoria durante la partida.

Paso 4: Desactivar la telemetría compartida (-XX:+PerfDisableSharedMem)

Por defecto, la máquina virtual de Java escribe constantemente pequeñas estadísticas de rendimiento en un archivo temporal dentro del directorio del usuario para permitir que herramientas externas de diagnóstico monitoreen el proceso. En sistemas con almacenamiento bajo carga constante, estas operaciones de escritura silenciosas pueden causar micro-congelamientos esporádicos. El parámetro siguiente neutraliza este mecanismo secundario:

-XX:+PerfDisableSharedMem

Caso técnico poco documentado: El mito de -XX:+UseNUMA y la saturación de hilos en CPUs de escritorio

Es muy frecuente ver en configuraciones compartidas de internet el argumento -XX:+UseNUMA, acompañado de la afirmación de que "activa todos los núcleos de tu procesador".

Desde el punto de vista de la arquitectura de computadores, esto es falso en un ordenador de escritorio convencional. NUMA (Non-Uniform Memory Access) es una tecnología diseñada exclusivamente para placas base empresariales de servidores que albergan dos o más zócalos de procesador independientes (múltiples procesadores físicos montados en la misma placa), donde cada chip tiene su propio canal de memoria cercano y debe comunicarse mediante un bus intermedio para acceder a la memoria del otro chip.

En un procesador de consumo de un solo zócalo (como una CPU Intel Core i7, i5 o AMD Ryzen estándar de escritorio), la memoria es completamente uniforme (UMA). Si colocas -XX:+UseNUMA en un procesador de escritorio convencional de cuatro o seis núcleos, Java intentará consultar al sistema operativo por nodos de memoria que no existen físicamente, introduciendo comprobaciones inútiles en el kernel de Windows. Peor aún: si se acompaña de comandos como -XX:ParallelGCThreads fijados en el número total de hilos del procesador (por ejemplo, 8 hilos en un i7-4790), cada vez que el recolector de basura realice una operación, acaparará la totalidad de los núcleos lógicos de la CPU, dejando al hilo de audio y al hilo de renderizado sin tiempo de procesamiento y provocando un congelamiento de imagen audible.

En procesadores de escritorio de 4 a 8 hilos, la recomendación técnica es no sobrecargar las directivas de hilos paralelos y dejar que el programador de tareas nativo de OpenJDK asigne los hilos de manera balanceada.

Cómo comprobar que la configuración de memoria es estable

Para verificar con datos objetivos que tus argumentos JVM están trabajando correctamente sin saturar el sistema:

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. Inspecciona el patrón de consumo: la memoria en uso debe aumentar de forma progresiva y suave (por ejemplo, subir de 40% a 70%) y luego descender limpiamente sin que la pantalla se congele ni un solo milisegundo al bajar. Este patrón regular en forma de "dientes de sierra" confirma que el recolector de basura está realizando limpiezas parciales eficientes.
4. Abre el Administrador de tareas de Windows (Ctrl + Shift + Esc) en la pestaña Rendimiento > Memoria y comprueba que la cantidad de "Memoria disponible" en el sistema operativo no baje nunca de 1.5 GB. Mientras Windows tenga margen de maniobra, Minecraft no sufrirá caídas de rendimiento externas.

Línea de argumentos recomendada lista para usar

Si buscas una configuración balanceada, probada y libre de parámetros obsoletos para jugar con mods en Java 17 o Java 21, utiliza esta base limpia (ajustando los 4G a 6G u 8G según la memoria de tu PC):

-Xms4G -Xmx4G -XX:+UseG1GC -XX:+AlwaysPreTouch -XX:+PerfDisableSharedMem

En lanzadores que permiten personalizar la instancia (como Nebula Launcher o perfiles avanzados de Mojang), este texto se introduce directamente en el campo JVM Arguments sin necesidad de alterar ningún archivo de configuración interno del sistema operativo.

Conclusión

La optimización de Java para Minecraft no consiste en acumular la mayor cantidad de comandos posibles, sino en aplicar los principios de la informática moderna: otorgar al juego la memoria justa que necesita, garantizar que Windows conserve recursos para sus controladores y permitir que los algoritmos modernos de recolección de residuos trabajen sin interferencias artificiales.