Tamaño máximo de almacenamiento dinámico de Java de una JVM de 32 bits en un sistema operativo de 64 bits

La pregunta no es sobre el tamaño máximo del montón en un sistema operativo de 32 bits, dado que los sistemas operativos de 32 bits tienen un tamaño máximo de memoria direccionable de 4 GB, y que el tamaño máximo del montón de la JVM depende de cuánta memoria libre contigua se puede reservar.

Estoy más interesado en conocer el tamaño de pila máximo (tanto teórico como prácticamente alcanzable) para una JVM de 32 bits que se ejecuta en un sistema operativo de 64 bits. Básicamente, estoy buscando respuestas similares a las cifras en una pregunta relacionada sobre SO .

En cuanto a por qué se usa una JVM de 32 bits en lugar de una de 64 bits, la razón no es técnica, sino administrativa / burocrática; probablemente sea demasiado tarde para instalar una JVM de 64 bits en el entorno de producción.

Las JVM de 32 bits que esperan tener una sola porción grande de memoria y usan punteros sin procesar no pueden usar más de 4 Gb (ya que ese es el límite de 32 bits que también se aplica a los punteros). Esto incluye Sun y, estoy bastante seguro, también implementaciones de IBM. No sé si, por ejemplo, JRockit u otros tienen una opción de memoria grande con sus implementaciones de 32 bits.

Si espera alcanzar este límite, debería considerar seriamente iniciar una pista paralela que valide una JVM de 64 bits para su entorno de producción para tenerla lista para cuando el entorno de 32 bits se estropee. De lo contrario, tendrá que hacer ese trabajo bajo presión, lo que nunca es agradable.

Editar 2014-05-15: Preguntas frecuentes de Oracle:

El límite de pila teórico máximo para la JVM de 32 bits es 4G. Debido a varias restricciones adicionales, como el intercambio disponible, el uso del espacio de direcciones del kernel, la fragmentación de la memoria y la sobrecarga de la VM, en la práctica el límite puede ser mucho menor. En la mayoría de los sistemas Windows modernos de 32 bits, el tamaño máximo del montón oscilará entre 1,4G y 1,6G. En los núcleos Solaris de 32 bits, el espacio de direcciones está limitado a 2G. En los sistemas operativos de 64 bits que ejecutan la máquina virtual de 32 bits, el tamaño máximo de pila puede ser mayor, acercándose a 4G en muchos sistemas Solaris.

( http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit )

Puede preguntar al Java Runtime:

public class MaxMemory {
    public static void main(String[] args) {
        Runtime rt = Runtime.getRuntime();
        long totalMem = rt.totalMemory();
        long maxMem = rt.maxMemory();
        long freeMem = rt.freeMemory();
        double megs = 1048576.0;

        System.out.println ("Total Memory: " + totalMem + " (" + (totalMem/megs) + " MiB)");
        System.out.println ("Max Memory:   " + maxMem + " (" + (maxMem/megs) + " MiB)");
        System.out.println ("Free Memory:  " + freeMem + " (" + (freeMem/megs) + " MiB)");
    }
}

Esto informará la "memoria máxima" según la asignación de montón predeterminada. Así que aún necesitarías jugar con -Xmx(en HotSpot ). Descubrí que al ejecutar Windows 7 Enterprise de 64 bits, mi JVM HotSpot de 32 bits puede asignar hasta 1577MiB:

[C: scratch]> java -Xmx1600M MaxMemory
Se produjo un error durante la inicialización de la VM
No se pudo reservar suficiente espacio para el montón de objetos
No se pudo crear la máquina virtual de Java.
[C: scratch]> java -Xmx1590M MaxMemory
Memoria total: 2031616 (1,9375 MiB)
Memoria máxima: 1654456320 (1577,8125 MiB)
Memoria libre: 1840872 (1,75559234619 MiB)
[C: cero]>

Mientras que con una JVM de 64 bits en el mismo sistema operativo, por supuesto, es mucho más alta (alrededor de 3TiB)

[C: scratch]> java -Xmx3560G MaxMemory
Se produjo un error durante la inicialización de la VM
No se pudo reservar suficiente espacio para el montón de objetos
[C: scratch]> java -Xmx3550G MaxMemory
Memoria total: 94240768 (89,875 MiB)
Memoria máxima: 3388252028928 (3184151,84297 MiB)
Memoria libre: 93747752 (89.4048233032 MiB)
[C: cero]>

Como ya han mencionado otros, depende del sistema operativo.

• Para Windows de 32 bits: será <2GB ( el libro interno de Windows dice 2GB para procesos de usuario)
• Para BSD / Linux de 32 bits: <3GB (del Devil Book)
• Para MacOS X de 32 bits: <4 GB (del libro interno de Mac OS X )
• No estoy seguro acerca de Solaris de 32 bits, pruebe el código anterior y avísenos.

Para un sistema operativo host de 64 bits, si la JVM es de 32 bits, seguirá dependiendo, probablemente como se muestra arriba.

- ACTUALIZACIÓN 20110905 : solo quería señalar algunas otras observaciones / detalles:

• El hardware en el que ejecuté esto era de 64 bits con 6 GB de RAM real instalada. El sistema operativo era Windows 7 Enterprise, 64 bits
• La cantidad real Runtime.MaxMemoryque se puede asignar también depende del conjunto de trabajo del sistema operativo . Una vez ejecuté esto mientras también tenía VirtualBox en ejecución y descubrí que no podía iniciar con éxito HotSpot JVM -Xmx1590My tenía que reducirlo. Esto también implica que puede obtener más de 1590M dependiendo del tamaño de su conjunto de trabajo en ese momento (aunque todavía mantengo que estará por debajo de 2GiB para 32 bits debido al diseño de Windows)

No especifica qué sistema operativo.

En Windows (para mi aplicación, una aplicación de gestión de riesgos de larga duración) observamos que no podíamos ir más allá de 1280 MB en Windows de 32 bits. Dudo que ejecutar una JVM de 32 bits por debajo de 64 bits haga alguna diferencia.

Portamos la aplicación a Linux y estamos ejecutando una JVM de 32 bits en hardware de 64 bits y hemos tenido una VM de 2,2 GB funcionando con bastante facilidad.

El mayor problema que puede tener es GC, dependiendo de para qué esté usando la memoria.

Desde 4.1.2 Tamaño del montón :

"Para un modelo de proceso de 32 bits, el tamaño máximo de dirección virtual del proceso suele ser de 4 GB, aunque algunos sistemas operativos lo limitan a 2 GB o 3 GB. El tamaño máximo de almacenamiento dinámico suele ser -Xmx3800m (1600m) para límites de 2 GB ), aunque la limitación real depende de la aplicación. Para los modelos de proceso de 64 bits, el máximo es esencialmente ilimitado ".

Encontré una respuesta bastante buena aquí: memoria máxima de Java en Windows XP .

Recientemente hemos tenido alguna experiencia con esto. Recientemente, hemos portado de Solaris (x86-64 Versión 5.10) a Linux (RedHat x86-64) y nos hemos dado cuenta de que tenemos menos memoria disponible para un proceso JVM de 32 bits en Linux que Solaris.

Para Solaris, esto casi llega a 4 GB (http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit).

Ejecutamos nuestra aplicación con -Xms2560m -Xmx2560m -XX: MaxPermSize = 512m -XX: PermSize = 512m sin problemas en Solaris durante los últimos años. Intenté moverlo a Linux y tuvimos problemas con errores aleatorios de memoria insuficiente al iniciar. Solo pudimos hacer que se iniciara de manera consistente en -Xms2300 -Xmx2300 . Luego, el soporte nos informó de esto.

Un proceso de 32 bits en Linux tiene un espacio máximo de direcciones direccionables de 3gb (3072mb) mientras que en Solaris es el total de 4gb (4096mb).

Las limitaciones de una JVM de 32 bits en un sistema operativo de 64 bits serán exactamente las mismas que las limitaciones de una JVM de 32 bits en un sistema operativo de 32 bits. Después de todo, la JVM de 32 bits se ejecutará en una máquina virtual de 32 bits (en el sentido de virtualización) por lo que no sabrá que se está ejecutando en un sistema operativo / máquina de 64 bits.

La única ventaja de ejecutar una JVM de 32 bits en un sistema operativo de 64 bits frente a un sistema operativo de 32 bits es que puede tener más memoria física y, por lo tanto, encontrará cambios / paginación con menos frecuencia. Sin embargo, esta ventaja solo se realiza plenamente cuando tiene varios procesos.

En cuanto a por qué se usa una JVM de 32 bits en lugar de una de 64 bits, la razón no es técnica sino administrativa / burocrática ...

Cuando trabajaba para BEA, descubrimos que la aplicación promedio en realidad funcionaba más lentamente en una JVM de 64 bits, que cuando se ejecutaba en una JVM de 32 bits. En algunos casos, el impacto en el rendimiento fue hasta un 25% más lento. Por lo tanto, a menos que su aplicación realmente necesite toda esa memoria adicional, sería mejor que configurara más servidores de 32 bits.

Según recuerdo, las tres justificaciones técnicas más comunes para el uso de 64 bits con las que se encontró el personal de servicios profesionales de BEA fueron:

1. La aplicación estaba manipulando múltiples imágenes masivas,
2. La aplicación estaba procesando números masivos,
3. La aplicación tenía una pérdida de memoria, el cliente era el principal en un contrato con el gobierno y no querían tomarse el tiempo y el gasto de rastrear la pérdida de memoria. (El uso de un montón de memoria masiva aumentaría el MTBF y aún así se pagaría al principal)

.

JROCKIT JVM actualmente propiedad de Oracle admite el uso de almacenamiento dinámico no contiguo, lo que permite que la JVM de 32 bits acceda a más de 3,8 GB de memoria cuando la JVM se ejecuta en un sistema operativo Windows de 64 bits. (2,8 GB cuando se ejecuta en un sistema operativo de 32 bits).

http://blogs.oracle.com/jrockit/entry/how_to_get_almost_3_gb_heap_on_windows

La JVM se puede descargar libremente (se requiere registro) en

http://www.oracle.com/technetwork/middleware/jrockit/downloads/index.html

Aquí hay algunas pruebas en Solaris y Linux de 64 bits

Solaris 10 - SPARC - Máquina T5220 con 32 GB de RAM (y aproximadamente 9 GB libres)

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3750m MaxMemory
Error occurred during initialization of VM
Could not reserve space for ObjectStartArray
$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3700m MaxMemory
Total Memory: 518520832 (494.5 MiB)
Max Memory:   3451912192 (3292.0 MiB)
Free Memory:  515815488 (491.91998291015625 MiB)
Current PID is: 28274
Waiting for user to press Enter to finish ...

$ java -version
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) Server VM (build 20.5-b03, mixed mode)

$ which java
/usr/bin/java
$ file /usr/bin/java
/usr/bin/java: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped, no debugging information available

$ prstat -p 28274
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
28274 user1     670M   32M sleep   59    0   0:00:00 0.0% java/35

Por cierto: aparentemente Java no asigna mucha memoria real con el inicio. Parecía tomar solo unos 100 MB por instancia iniciada (comencé 10)

Solaris 10 - x86 - VMWare VM con 8 GB de RAM (aproximadamente 3 GB libres *)

Los 3 GB de RAM libre no son realmente ciertos. Hay una gran cantidad de RAM que usan las cachés de ZFS, pero no tengo acceso de root para verificar cuánto exactamente

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3650m MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3600m MaxMemory
Total Memory: 516423680 (492.5 MiB)
Max Memory:   3355443200 (3200.0 MiB)
Free Memory:  513718336 (489.91998291015625 MiB)
Current PID is: 26841
Waiting for user to press Enter to finish ...

$ java -version
java version "1.6.0_41"
Java(TM) SE Runtime Environment (build 1.6.0_41-b02)
Java HotSpot(TM) Server VM (build 20.14-b01, mixed mode)

$ which java
/usr/bin/java

$ file /usr/bin/java
/usr/bin/java:  ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, no debugging information available

$ prstat -p 26841
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
26841 user1     665M   22M sleep   59    0   0:00:00 0.0% java/12

RedHat 5.5 - x86 - VMWare VM con 4 GB de RAM (aproximadamente 3.8 GB usados ​​- 200 MB en búferes y 3.1 GB en cachés, por lo que aproximadamente 3 GB libres)

$ alias java='$HOME/jre/jre1.6.0_34/bin/java'

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3500m MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3450m MaxMemory
Total Memory: 514523136 (490.6875 MiB)
Max Memory:   3215654912 (3066.6875 MiB)
Free Memory:  511838768 (488.1274871826172 MiB)
Current PID is: 21879
Waiting for user to press Enter to finish ...

$ java -version
java version "1.6.0_34"
Java(TM) SE Runtime Environment (build 1.6.0_34-b04)
Java HotSpot(TM) Server VM (build 20.9-b04, mixed mode)

$ file $HOME/jre/jre1.6.0_34/bin/java
/home/user1/jre/jre1.6.0_34/bin/java: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped

$ cat /proc/21879/status | grep ^Vm
VmPeak:  3882796 kB
VmSize:  3882796 kB
VmLck:         0 kB
VmHWM:     12520 kB
VmRSS:     12520 kB
VmData:  3867424 kB
VmStk:        88 kB
VmExe:        40 kB
VmLib:     14804 kB
VmPTE:        96 kB

Misma máquina usando JRE 7

$ alias java='$HOME/jre/jre1.7.0_21/bin/java'

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3500m MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3450m MaxMemory
Total Memory: 514523136 (490.6875 MiB)
Max Memory:   3215654912 (3066.6875 MiB)
Free Memory:  511838672 (488.1273956298828 MiB)
Current PID is: 23026
Waiting for user to press Enter to finish ...

$ java -version
java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) Server VM (build 23.21-b01, mixed mode)

$ file $HOME/jre/jre1.7.0_21/bin/java
/home/user1/jre/jre1.7.0_21/bin/java: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

$ cat /proc/23026/status | grep ^Vm
VmPeak:  4040288 kB
VmSize:  4040288 kB
VmLck:         0 kB
VmHWM:     13468 kB
VmRSS:     13468 kB
VmData:  4024800 kB
VmStk:        88 kB
VmExe:         4 kB
VmLib:     10044 kB
VmPTE:       112 kB

Debería ser mucho mejor

Para una JVM de 32 bits que se ejecuta en un host de 64 bits, imagino que lo que queda para el montón será cualquier espacio virtual no fragmentado que esté disponible después de la JVM, sus propias DLL y cualquier material de compatibilidad del sistema operativo de 32 bits que se haya cargado. Como una suposición salvaje, pensaría que 3GB deberían ser posibles, pero cuánto mejor eso depende de qué tan bien lo esté haciendo en 32-bit-host-land.

Además, incluso si pudiera hacer un montón gigante de 3 GB, es posible que no desee hacerlo, ya que esto hará que las pausas de GC se vuelvan potencialmente problemáticas. Algunas personas simplemente ejecutan más JVM para usar la memoria adicional en lugar de una gigante. Me imagino que están ajustando las JVM en este momento para que funcionen mejor con montones gigantes.

Es un poco difícil saber exactamente cuánto mejor puede hacer. Supongo que su situación de 32 bits se puede determinar fácilmente mediante un experimento. Ciertamente es difícil de predecir de manera abstracta, ya que muchas cosas influyen en ello, particularmente porque el espacio virtual disponible en hosts de 32 bits está bastante restringido. El montón debe existir en la memoria virtual contigua, por lo que la fragmentación del espacio de direcciones para dll y el uso interno del espacio de direcciones por parte del kernel del sistema operativo determinará el rango de posibles asignaciones.

El SO utilizará parte del espacio de direcciones para mapear dispositivos HW y sus propias asignaciones dinámicas. Si bien esta memoria no está asignada al espacio de direcciones del proceso de Java, el kernel del sistema operativo no puede acceder a ella y a su espacio de direcciones al mismo tiempo, por lo que limitará el tamaño del espacio virtual de cualquier programa.

La carga de DLL depende de la implementación y el lanzamiento de la JVM. La carga del kernel del sistema operativo depende de una gran cantidad de cosas, el lanzamiento, el HW, cuántas cosas ha mapeado hasta ahora desde el último reinicio, quién sabe ...

En resumen

Apuesto a que obtienes 1-2 GB en tierra de 32 bits y aproximadamente 3 en 64 bits, por lo que una mejora general de aproximadamente el doble .

En Solaris, el límite ha sido de aproximadamente 3,5 GB desde Solaris 2.5. (hace unos 10 años)

Tenía los mismos problemas con la JVM que usa App Inventor para Android Blocks Editor. Establece el montón en 925 m como máximo. Esto no es suficiente, pero no pude configurarlo a más de 1200 m, dependiendo de varios factores aleatorios en mi máquina.

Descargué Nightly, el navegador beta de 64 bits de Firefox, y también la versión JAVA 7 de 64 bits.

Todavía no he encontrado mi nuevo límite de almacenamiento dinámico, pero acabo de abrir una JVM con un tamaño de almacenamiento dinámico de 5900 m . ¡No hay problema!

Estoy ejecutando Win 7 64 bit Ultimate en una máquina con 24 GB de RAM.

Intenté configurar el tamaño del montón hasta 2200M en una máquina Linux de 32 bits y JVM funcionó bien. La JVM no se inició cuando la configuré en 2300M.

Este es un ajuste pesado, pero puede obtener un montón de 3 GB.

http://www.microsofttranslator.com/bv.aspx?from=&to=en&a=http://forall.ru-board.com/egor23/online/FAQ/Virtual_Memory/Limits_Virtual_Memory.html

un punto más aquí para JVM hotspot de 32 bits: - la capacidad del montón nativo = 4 Gig - Java Heap - PermGen;

Puede resultar especialmente complicado para JVM de 32 bits, ya que Java Heap y el Heap nativo están en una carrera. Cuanto más grande sea su Java Heap, más pequeño será el Heap nativo. Intentar configurar un montón grande para una máquina virtual de 32 bits, por ejemplo, .2.5 GB + aumenta el riesgo de OutOfMemoryError nativo dependiendo de la huella de su aplicación, número de subprocesos, etc.

La limitación también proviene del hecho de que, para una 32 bitmáquina virtual, la heapmisma tiene que comenzar en la dirección cero si desea todos esos4GB .

Piense en ello, si desea hacer referencia a algo a través de:

0000....0001

es decir, una referencia que tiene esta representación de bits en particular, significa que está intentando acceder a la primera memoria del montón. Para que eso sea posible, el montón debe comenzar en la dirección cero. Pero eso nunca sucede, comienza en algún desplazamiento desde cero:

    | ....               .... {heap_start .... heap_end} ... |
 --> (this can't be referenced) <--

Debido a que el montón nunca comienza desde la dirección cero en un OS, hay bastantes bits que nunca se utilizan desde una 32referencia de bits y, por lo tanto, el montón al que se puede hacer referencia es menor.

4gb teórico, pero en la práctica (para IBM JVM):

Win 2k8 64, IBM Websphere Application Server 8.5.5 de 32 bits

C:\IBM\WebSphere\AppServer\bin>managesdk.bat -listAvailable -verbose CWSDK1003I: Доступные SDK: CWSDK1005I: Имя SDK: 1.6_32 - com.ibm.websphere.sdk.version.1.6_32=1.6 - com.ibm.websphere.sdk.bits.1.6_32=32 - com.ibm.websphere.sdk.location.1.6_32=${WAS_INSTALL_ROOT}/java - com.ibm.websphere.sdk.platform.1.6_32=windows - com.ibm.websphere.sdk.architecture.1.6_32=x86_32 - com.ibm.websphere.sdk.nativeLibPath.1.6_32=${WAS_INSTALL_ROOT}/lib/native/win /x86_32/ CWSDK1001I: Задача managesdk выполнена успешно. C:\IBM\WebSphere\AppServer\java\bin>java -Xmx2036 MaxMemory JVMJ9GC017E -Xmx слишком мала, должна быть не меньше 1 M байт JVMJ9VM015W Ошибка инициализации для библиотеки j9gc26(2): Не удалось инициализи ровать Could not create the Java virtual machine. C:\IBM\WebSphere\AppServer\java\bin>java -Xmx2047M MaxMemory Total Memory: 4194304 (4.0 MiB) Max Memory: 2146435072 (2047.0 MiB) Free Memory: 3064536 (2.9225692749023438 MiB) C:\IBM\WebSphere\AppServer\java\bin>java -Xmx2048M MaxMemory JVMJ9VM015W Ошибка инициализации для библиотеки j9gc26(2): Не удалось создать эк земпляр кучи; запрошено 2G Could not create the Java virtual machine.

RHEL 6.4 64, IBM Websphere Application Server 8.5.5 32 bits

[bin]./java -Xmx3791M MaxMemory Total Memory: 4194304 (4.0 MiB) Max Memory: 3975151616 (3791.0 MiB) Free Memory: 3232992 (3.083221435546875 MiB) [root@nagios1p bin]# ./java -Xmx3793M MaxMemory Total Memory: 4194304 (4.0 MiB) Max Memory: 3977248768 (3793.0 MiB) Free Memory: 3232992 (3.083221435546875 MiB) [bin]# /opt/IBM/WebSphere/AppServer/bin/managesdk.sh -listAvailable -verbose CWSDK1003I: Available SDKs : CWSDK1005I: SDK name: 1.6_32 - com.ibm.websphere.sdk.version.1.6_32=1.6 - com.ibm.websphere.sdk.bits.1.6_32=32 - com.ibm.websphere.sdk.location.1.6_32=${WAS_INSTALL_ROOT}/java - com.ibm.websphere.sdk.platform.1.6_32=linux - com.ibm.websphere.sdk.architecture.1.6_32=x86_32 -com.ibm.websphere.sdk.nativeLibPath.1.6_32=${WAS_INSTALL_ROOT}/lib/native/linux/x86_32/ CWSDK1001I: Successfully performed the requested managesdk task.