Tamanho máximo de heap Java de uma JVM de 32 bits em um sistema operacional de 64 bits

A questão não é sobre o tamanho máximo de heap em um sistema operacional de 32 bits, visto que os sistemas operacionais de 32 bits têm um tamanho máximo de memória endereçável de 4 GB e que o tamanho máximo de heap da JVM depende de quanta memória livre contígua pode ser reservada.

Estou mais interessado em saber o tamanho de heap máximo (teórico e prático) para uma JVM de 32 bits em execução em um sistema operacional de 64 bits. Basicamente, estou procurando respostas semelhantes às figuras em uma pergunta relacionada no SO .

Quanto ao motivo pelo qual uma JVM de 32 bits é usada em vez de uma de 64 bits, o motivo não é técnico, mas administrativo / burocrático - provavelmente é tarde demais para instalar uma JVM de 64 bits no ambiente de produção.

JVMs de 32 bits que esperam ter um único pedaço grande de memória e usam ponteiros brutos não podem usar mais de 4 Gb (uma vez que esse é o limite de 32 bits que também se aplica a ponteiros). Isso inclui as implementações da Sun e - tenho certeza - também da IBM. Não sei se, por exemplo, JRockit ou outros têm uma opção de grande memória com suas implementações de 32 bits.

Se você espera atingir esse limite, deve considerar seriamente iniciar uma trilha paralela validando uma JVM de 64 bits para o seu ambiente de produção, para que esteja pronto para quando o ambiente de 32 bits quebrar. Caso contrário, você terá que fazer esse trabalho sob pressão, o que nunca é bom.

Editar 15/05/2014: Perguntas frequentes da Oracle:

O limite máximo teórico de heap para a JVM de 32 bits é 4G. Devido a várias restrições adicionais, como troca disponível, uso do espaço de endereço do kernel, fragmentação da memória e sobrecarga da VM, na prática, o limite pode ser muito menor. Na maioria dos sistemas Windows de 32 bits modernos, o tamanho máximo de heap irá variar de 1,4 G a 1,6 G. Em kernels Solaris de 32 bits, o espaço de endereço é limitado a 2G. Em sistemas operacionais de 64 bits executando a VM de 32 bits, o tamanho máximo de heap pode ser maior, chegando a 4G em muitos sistemas Solaris.

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

Você pode perguntar ao 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)");
    }
}

Isso relatará a "Memória máxima" com base na alocação de heap padrão. Portanto, você ainda precisa jogar com -Xmx(no HotSpot ). Descobri que rodando no Windows 7 Enterprise de 64 bits, minha JVM HotSpot de 32 bits pode alocar até 1577 MiB:

[C: scratch]> java -Xmx1600M MaxMemory
Ocorreu um erro durante a inicialização da VM
Não foi possível reservar espaço suficiente para a pilha do objeto
Não foi possível criar a máquina virtual Java.
[C: scratch]> java -Xmx1590M MaxMemory
Memória total: 2031616 (1,9375 MiB)
Memória máxima: 1654456320 (1577,8125 MiB)
Memória livre: 1840872 (1.75559234619 MiB)
[C: scratch]>

Considerando que, com uma JVM de 64 bits no mesmo sistema operacional, é claro que é muito maior (cerca de 3TiB)

[C: scratch]> java -Xmx3560G MaxMemory
Ocorreu um erro durante a inicialização da VM
Não foi possível reservar espaço suficiente para a pilha do objeto
[C: scratch]> java -Xmx3550G MaxMemory
Memória total: 94240768 (89,875 MiB)
Memória máxima: 3388252028928 (3184151.84297 MiB)
Memória livre: 93747752 (89,4048233032 MiB)
[C: scratch]>

Como outros já mencionaram, depende do sistema operacional.

• Para Windows de 32 bits: será <2 GB ( o livro interno do Windows diz 2 GB para processos do usuário)
• Para BSD / Linux de 32 bits: <3 GB (do Devil Book)
• Para MacOS X de 32 bits: <4 GB (do livro interno do Mac OS X )
• Não tenho certeza sobre o Solaris de 32 bits, tente o código acima e nos informe.

Para um sistema operacional host de 64 bits, se a JVM for de 32 bits, ela ainda dependerá, provavelmente como demonstrado acima.

- ATUALIZAÇÃO 20110905 : Eu só queria apontar algumas outras observações / detalhes:

• O hardware em que eu executei isso era de 64 bits com 6 GB de RAM real instalada. O sistema operacional era o Windows 7 Enterprise, 64 bits
• A quantidade real Runtime.MaxMemoryque pode ser alocada também depende do conjunto de trabalho do sistema operacional . Uma vez eu executei isso enquanto também tinha o VirtualBox em execução e descobri que não conseguia iniciar o HotSpot JVM com -Xmx1590Me tinha que diminuir. Isso também implica que você pode obter mais de 1590 MB, dependendo do tamanho do seu conjunto de trabalho no momento (embora eu ainda afirme que será inferior a 2 GiB para 32 bits por causa do design do Windows)

Você não especifica qual sistema operacional.

No Windows (para meu aplicativo - um aplicativo de gerenciamento de risco de longa duração), observamos que não podíamos ir além de 1280 MB no Windows de 32 bits. Duvido que rodar uma JVM de 32 bits em 64 bits faça alguma diferença.

Portamos o aplicativo para Linux e estamos executando uma JVM de 32 bits em hardware de 64 bits e temos uma VM de 2,2 GB rodando com bastante facilidade.

O maior problema que você pode ter é o GC, dependendo para o que você está usando a memória.

De 4.1.2 Dimensionamento de heap :

"Para um modelo de processo de 32 bits, o tamanho máximo do endereço virtual do processo é normalmente de 4 GB, embora alguns sistemas operacionais limitem isso a 2 GB ou 3 GB. O tamanho máximo de heap é normalmente -Xmx3800m (1600m) para limites de 2 GB ), embora a limitação real dependa do aplicativo. Para modelos de processo de 64 bits, o máximo é essencialmente ilimitado. "

Encontramos uma resposta muito boa aqui: memória máxima do Java no Windows XP .

Recentemente, tivemos alguma experiência com isso. Transferimos do Solaris (x86-64 versão 5.10) para o Linux (RedHat x86-64) recentemente e percebemos que temos menos memória disponível para um processo JVM de 32 bits no Linux do que Solaris.

Para Solaris, isso quase chega a 4 GB (http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit).

Executamos nosso aplicativo com -Xms2560m -Xmx2560m -XX: MaxPermSize = 512m -XX: PermSize = 512m sem problemas no Solaris nos últimos dois anos. Tentei movê-lo para o Linux e tivemos problemas com erros aleatórios de falta de memória na inicialização. Conseguimos apenas fazer com que ele inicializasse consistentemente em -Xms2300 -Xmx2300 . Então, fomos avisados ​​disso pelo suporte.

Um processo de 32 bits no Linux tem um espaço de endereço endereçável máximo de 3 gb (3072 MB), enquanto no Solaris é de 4 GB (4096 MB).

As limitações de uma JVM de 32 bits em um sistema operacional de 64 bits serão exatamente as mesmas que as limitações de uma JVM de 32 bits em um sistema operacional de 32 bits. Afinal, o JVM de 32 bits será executado em uma máquina virtual de 32 bits (no sentido de virtualização), portanto, não saberá que está executando em um sistema operacional / máquina de 64 bits.

A única vantagem de executar uma JVM de 32 bits em um sistema operacional de 64 bits em comparação com um sistema operacional de 32 bits é que você pode ter mais memória física e, portanto, encontrará troca / paginação com menos frequência. No entanto, essa vantagem só é totalmente percebida quando você tem vários processos.

Quanto ao motivo pelo qual uma JVM de 32 bits é usada em vez de 64 bits, o motivo não é técnico, mas administrativo / burocrático ...

Quando eu estava trabalhando para a BEA, descobrimos que o aplicativo médio na verdade rodava mais devagar em uma JVM de 64 bits do que quando rodava em uma JVM de 32 bits. Em alguns casos, o impacto no desempenho chegou a ser 25% mais lento. Portanto, a menos que seu aplicativo realmente precise de toda aquela memória extra, seria melhor configurar mais servidores de 32 bits.

Pelo que me lembro, as três justificativas técnicas mais comuns para o uso de 64 bits que o pessoal de serviços profissionais da BEA encontrou foram:

1. O aplicativo estava manipulando várias imagens enormes,
2. O aplicativo estava fazendo cálculos massivos,
3. O aplicativo tinha um vazamento de memória, o cliente era o principal em um contrato com o governo e eles não queriam perder tempo e despesas para rastrear o vazamento de memória. (Usar um heap de memória massivo aumentaria o MTBF e o principal ainda seria pago)

.

O JROCKIT JVM atualmente de propriedade da Oracle oferece suporte ao uso de heap não contíguo, permitindo que o JVM de 32 bits acesse mais de 3,8 GB de memória quando o JVM está sendo executado em um sistema operacional Windows de 64 bits. (2,8 GB quando executado em um sistema operacional de 32 bits).

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

O JVM pode ser baixado gratuitamente (requer registro) em

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

Aqui estão alguns testes em Solaris e Linux de 64 bits

Solaris 10 - SPARC - máquina T5220 com 32 GB de RAM (e cerca de 9 GB de espaço livre)

$ 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

BTW: Aparentemente, o Java não aloca muita memória real com a inicialização. Pareceu levar apenas cerca de 100 MB por instância iniciada (comecei 10)

Solaris 10 - x86 - VMWare VM com 8 GB de RAM (cerca de 3 GB livres *)

Os 3 GB de RAM livres não são verdadeiros. Há um grande pedaço de RAM que os caches ZFS usam, mas não tenho acesso root para verificar quanto exatamente

$ 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 com 4 GB de RAM (cerca de 3,8 GB usados ​​- 200 MB em buffers e 3,1 GB em caches, ou seja, cerca de 3 GB livres)

$ 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

Mesma 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

Deve ser muito melhor

Para uma JVM de 32 bits em execução em um host de 64 bits, imagino que o que sobra para o heap será qualquer espaço virtual não fragmentado disponível após a JVM, suas próprias DLLs e qualquer material de compatibilidade do sistema operacional de 32 bits carregado. Eu acho que 3 GB deveria ser possível, mas o quanto isso é melhor depende de como você está se saindo em um host de 32 bits.

Além disso, mesmo se você pudesse fazer um heap gigante de 3 GB, você pode não querer, pois isso tornará as pausas do GC potencialmente problemáticas. Algumas pessoas simplesmente executam mais JVMs para usar a memória extra em vez de uma gigante. Eu imagino que eles estão ajustando o JVM agora para funcionar melhor com pilhas gigantes.

É um pouco difícil saber exatamente o quanto você pode fazer melhor. Eu acho que sua situação de 32 bits pode ser facilmente determinada por experimento. Certamente é difícil prever abstratamente, já que muitas coisas influenciam nisso, especialmente porque o espaço virtual disponível em hosts de 32 bits é bastante restrito. O heap precisa existir em memória virtual contígua, portanto, fragmentação do espaço de endereço para dll e uso interno do espaço de endereço pelo kernel do sistema operacional irão determinar o intervalo de alocações possíveis.

O SO usará parte do espaço de endereço para mapear dispositivos HW e suas próprias alocações dinâmicas. Embora essa memória não esteja mapeada no espaço de endereço do processo java, o kernel do sistema operacional não pode acessá-la e ao seu espaço de endereço ao mesmo tempo, portanto, limitará o tamanho do espaço virtual de qualquer programa.

O carregamento de DLLs depende da implementação e do lançamento da JVM. Carregar o kernel do SO depende de um grande número de coisas, o lançamento, o HW, quantas coisas ele mapeou até agora desde a última reinicialização, quem sabe ...

Em suma

Aposto que você obtém 1-2 GB em 32 bits e cerca de 3 em 64 bits, portanto, uma melhoria geral de cerca de 2x .

No Solaris, o limite é de cerca de 3,5 GB desde o Solaris 2.5. (cerca de 10 anos atrás)

Eu estava tendo os mesmos problemas com o JVM que o App Inventor para Android Blocks Editor usa. Ele define a pilha em 925 m máx. Isso não é suficiente, mas eu não poderia definir mais do que cerca de 1200m, dependendo de vários fatores aleatórios em minha máquina.

Eu baixei Nightly, o navegador beta de 64 bits do Firefox, e também a versão JAVA 7 de 64 bits.

Ainda não encontrei meu novo limite de heap, mas acabei de abrir uma JVM com tamanho de heap de 5900m . Sem problemas!

Estou executando o Win 7 64 bit Ultimate em uma máquina com 24 GB de RAM.

Eu tentei definir o tamanho do heap até 2200M em uma máquina Linux de 32 bits e a JVM funcionou bem. O JVM não começou quando eu o configurei para 2300M.

Este é um ajuste pesado, mas você pode obter um heap 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

mais um ponto aqui para JVM de ponto de acesso de 32 bits: - a capacidade de heap nativa = 4 Gig - Java Heap - PermGen;

Pode ser especialmente complicado para a JVM de 32 bits, pois o Java Heap e o Heap nativo estão em uma corrida. Quanto maior for o Heap Java, menor será o Heap nativo. A tentativa de configurar um grande Heap para uma VM de 32 bits, por exemplo, 2,5 GB +, aumenta o risco de OutOfMemoryError nativo, dependendo da área de cobertura de seu (s) aplicativo (s), número de Threads, etc.

A limitação também vem do fato de que para uma 32 bitVM, o heappróprio tem que começar no endereço zero se você quiser todos eles 4GB.

Pense nisso, se você quiser fazer referência a algo por meio de:

0000....0001

ou seja: uma referência que tem essa representação de bits em particular, significa que você está tentando acessar a primeira memória do heap. Para que isso seja possível, o heap deve começar no endereço zero. Mas isso nunca acontece, começa em algum deslocamento de zero:

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

Como o heap nunca começa do endereço zero em um OS, há alguns bits que nunca são usados ​​a partir de uma 32referência de bits e, como tal, o heap que pode ser referenciado é menor.

Teórico 4gb, mas na prática (para IBM JVM):

Win 2k8 64, IBM Websphere Application Server 8.5.5 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.