Almacenamiento dinámico dividido (solo Windows, en desuso)

Muchas cargas de trabajo de aplicaciones Java™ dependen del tamaño del almacenamiento dinámico de Java. El SDK puede utilizar un almacenamiento dinámico dividido para solucionar las restricciones en el espacio de memoria de Windows de 32 bits y proporcionar un tamaño de almacenamiento dinámico máximo más grande. Esta característica puede ser útil para aplicaciones que deben ejecutarse en la JVM de 32 bits (por ejemplo, debido a bibliotecas JNI de 32 bits, un sistema operativo de 32 bits o hardware de 32 bits) pero que necesitan almacenamientos dinámicos Java grandes.

Nota: La opción de línea de mandatos -Xgc:splitheap ha quedado en desuso en la versión 8 y se eliminará de futuras versiones del SDK de IBM .

Una interrupción en el espacio de direcciones de Windows limita el almacenamiento dinámico de Java a menos de 2 GB. Utilice un almacenamiento dinámico dividido para permitir que el almacenamiento dinámico de Java exista en ambos lados de la interrupción en el espacio de direcciones. Tal vez pueda asignar un almacenamiento dinámico más grande en comparación con el uso de un área contigua de memoria. Mediante el uso de un almacenamiento dinámico más grande, puede asignar más objetos antes de realizar una recopilación de basura y puede aumentar el número de objetos activos que puede utilizar antes de que se produzca una excepción OutOfMemoryError.

Utilice la opción de línea de mandatos -Xgc:splitheap (disponible sólo en la JVM de 32 bits de Windows) para habilitar el almacenamiento dinámico dividido. Cuando se utiliza esta opción, también se habilita el siguiente comportamiento:
  • El recopilador de basura se ve obligado a utilizar la política de recogida de basura gencon (simultánea generacional).
  • Las áreas nuevas y antiguas del almacenamiento dinámico de Java generacional se asignan en áreas separadas de memoria.
  • El redimensionamiento de las áreas de memoria nuevas y antiguas está inhabilitado.
No se recomienda un almacenamiento dinámico dividido si la aplicación funciona de alguna de las maneras siguientes:
  • Su rendimiento es muy bajo en la política de recopilación de basura gencon.
  • Carga un número muy elevado de clases.
  • Utiliza grandes cantidades de memoria del sistema nativa en bibliotecas JNI; el almacenamiento dinámico de Java de mayor tamaño puede reservar demasiado espacio de direcciones de la aplicación.
Restricción: Un proceso de 32 bits de Windows está limitado a un espacio de direcciones de 2 GB a menos que se especifique la opción /3GB en el archivo boot.ini . Consulte Soporte para direcciones grandes de 32 bits de Windows en la guía del usuario del SDK de para obtener más información.

Con un almacenamiento dinámico dividido, el área antigua está comprometida con el tamaño máximo (establecido con -Xmox) en una región inferior de memoria y el área nueva está comprometida con el tamaño máximo (establecido con -Xmnx) en una región superior de memoria.

Errores de asignación

Con un almacenamiento dinámico dividido, la JVM puede fallar durante el arranque de varias maneras. Los siguientes mensajes se deben a un error producido al asignar un almacenamiento dinámico dividido:
JVMJ9GC064 No se ha conseguido asignar espacio antiguo
No hay suficiente espacio libre en la memoria inferior para asignar el área antigua. Para resolver el problema, reduzca -Xmox.
JVMJ9GC065 Se ha producido un error al asignar espacio nuevo
No hay suficiente espacio libre en la memoria superior para asignar el área nueva. Para resolver el problema, reduzca -Xmnx.
JVMJ9GC066 No se ha podido asignar la geometría necesaria de memoria de almacenamiento dinámico dividido
El área nueva se asignó en un valor inferior al área antigua. Para resolver el problema, reduzca -Xmx.

Tamaños máximos de almacenamiento dinámico

Los tamaños máximos típicos de almacenamiento dinámico son los siguientes:

Windows 7 de 32 bits en hardware de 32 bits utilizando la JVM 32–bit
Área antigua de 1800 MiB y área nueva de 1000 MiB.
-Xgc:splitheap -Xmx2800m -Xmox1800m
Windows 7 de 64 bits en hardware de 64 bits utilizando la JVM 32–bit
Área antigua de 1700 MiB y área nueva de 2000 MiB.
-Xgc:splitheap -Xmx3700m -Xmox1700m

Las aplicaciones tienen límites inferiores si cargan un gran número de clases, cargan un gran número de bibliotecas nativas o inician varias hebras.