make - swing windows java
¿Cuál es el tamaño de montón más grande posible con una JVM de 64 bits? (5)
El valor de montón máximo teórico que se puede establecer con -Xmx en un sistema de 32 bits es, por supuesto, 2^32 bytes, pero normalmente (consulte: Descripción del tamaño máximo de almacenamiento dinámico de JVM - 32 bits frente a 64 bits ) no se pueden usar todos los 4 GB.
Para una JVM de 64 bits que se ejecuta en un sistema operativo de 64 bits en una máquina de 64 bits, ¿hay algún límite además del límite teórico de 2^64 bytes o 16 exabytes?
Sé que por varias razones (principalmente recolección de basura), montones excesivamente grandes pueden no ser prudentes , pero a la luz de la lectura sobre servidores con terrabytes de RAM, me pregunto qué es posible .
Para una JVM de 64 bits que se ejecuta en un sistema operativo de 64 bits en una máquina de 64 bits, ¿hay algún límite además del límite teórico de 2 ^ 64 bytes o 16 exabytes?
También debe tener en cuenta los límites de hardware. Si bien los punteros pueden ser de 64 bits, las CPU actuales solo pueden ocupar menos de 2 ^ 64 bytes de memoria virtual .
Con punteros sin comprimir, la JVM de punto clave necesita un espacio continuo de direcciones virtuales para su almacenamiento dinámico. Entonces, el segundo obstáculo después del hardware es que el sistema operativo proporciona una porción tan grande, no todos los sistemas operativos lo admiten.
Y el tercero es practicidad. Incluso si puede tener tanta memoria virtual, eso no significa que las CPU soporten tanta memoria física, y sin memoria física terminará intercambiando, lo que afectará adversamente el rendimiento de la JVM porque los GC generalmente tienen que tocar una gran fracción del montón
Como otras respuestas mencionan los ups comprimidos: Al topar la alineación del objeto a más de 8 bytes, los límites con oops comprimidos pueden aumentarse más allá de los 32 GB.
Intenté -Xmx32255M es aceptado por vmargs para oops comprimidos.
La respuesta depende claramente de la implementación de JVM. Azul afirma que su JVM
puede escalar ... a más de 1/2 Terabyte de memoria
Con "escala de lata" parecen significar "carreras de pozos", en lugar de "correr en absoluto".
Si desea utilizar referencias de 32 bits, su capacidad está limitada a 32 GB.
Sin embargo, si está dispuesto a utilizar referencias de 64 bits, es probable que el tamaño esté limitado por su sistema operativo, al igual que con la JVM de 32 bits. por ejemplo, en Windows de 32 bits, esto es de 1,2 a 1,5 GB.
Nota: querrá que su pila JVM encaje en la memoria principal, idealmente dentro de una región NUMA. Eso es alrededor de 1 TB en las máquinas más grandes. Si su JVM abarca regiones NUMA, el acceso a la memoria y el GC en particular tomarán mucho más tiempo. Si su pila JVM comienza a intercambiarla, el GC puede demorar horas, o incluso puede inutilizar su máquina, ya que agita la unidad de intercambio.
Nota: Puede acceder a la memoria directa grande y a los tamaños mapeados en memoria incluso si utiliza referencias de 32 bits en su pila. es decir, usar mucho más de 32 GB.
Oops comprimidos en el Hotspot JVM
Los oops comprimidos representan punteros administrados (en muchos lugares, pero no en todos, en la JVM) como valores de 32 bits que deben escalarse por un factor de 8 y agregarse a una dirección base de 64 bits para encontrar el objeto al que se refieren. Esto permite que las aplicaciones aborden hasta cuatro mil millones de objetos (no bytes) o un tamaño de almacenamiento dinámico de hasta aproximadamente 32 Gb. Al mismo tiempo, la compacidad de la estructura de datos es competitiva con el modo ILP32.
Windows impone un límite de memoria por proceso, puede ver lo que es para cada versión here
Ver:
User-mode virtual address space for each 64-bit process; With IMAGE_FILE_LARGE_ADDRESS_AWARE set (default): x64: 8 TB Intel IPF: 7 TB 2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared