Dimensione massima dell'heap Java di una JVM a 32 bit su un sistema operativo a 64 bit

La domanda non riguarda la dimensione massima dell'heap su un sistema operativo a 32 bit, dato che i sistemi operativi a 32 bit hanno una dimensione massima della memoria indirizzabile di 4 GB e che la dimensione massima dell'heap della JVM dipende dalla quantità di memoria libera contigua che può essere riservata.

Sono più interessato a conoscere la dimensione massima dell'heap (sia teorica che praticamente ottenibile) per una JVM a 32 bit in esecuzione in un sistema operativo a 64 bit. Fondamentalmente, sto cercando risposte simili alle figure in una domanda correlata su SO .

Per quanto riguarda il motivo per cui viene utilizzata una JVM a 32 bit invece di una a 64 bit, il motivo non è tecnico ma piuttosto amministrativo / burocratico: probabilmente è troppo tardi per installare una JVM a 64 bit nell'ambiente di produzione.

Le JVM a 32 bit che prevedono di avere un unico grande blocco di memoria e utilizzano puntatori non elaborati non possono utilizzare più di 4 GB (poiché questo è il limite di 32 bit che si applica anche ai puntatori). Ciò include Sun e, ne sono abbastanza sicuro, anche le implementazioni IBM. Non so se ad esempio JRockit o altri abbiano un'opzione di memoria di grandi dimensioni con le loro implementazioni a 32 bit.

Se prevedi di raggiungere questo limite, dovresti prendere in seria considerazione l'avvio di una traccia parallela che convalidi una JVM a 64 bit per il tuo ambiente di produzione in modo da averlo pronto per quando l'ambiente a 32 bit si interrompe. Altrimenti dovrai fare quel lavoro sotto pressione, il che non è mai bello.

Modifica 15/05/2014: FAQ Oracle:

Il limite di heap teorico massimo per la JVM a 32 bit è 4G. A causa di vari vincoli aggiuntivi come lo scambio disponibile, l'utilizzo dello spazio di indirizzi del kernel, la frammentazione della memoria e il sovraccarico della VM, in pratica il limite può essere molto più basso. Sulla maggior parte dei moderni sistemi Windows a 32 bit, la dimensione massima dell'heap varia da 1,4 G a 1,6 G. Sui kernel Solaris a 32 bit lo spazio degli indirizzi è limitato a 2G. Sui sistemi operativi a 64 bit che eseguono la VM a 32 bit, la dimensione massima dell'heap può essere maggiore, avvicinandosi a 4G su molti sistemi Solaris.

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

Puoi chiedere a 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)");
    }
}

Questo riporterà la "Memoria massima" basata sull'allocazione predefinita dell'heap. Quindi dovresti ancora giocare con -Xmx(su HotSpot ). Ho scoperto che in esecuzione su Windows 7 Enterprise a 64 bit, la mia JVM HotSpot a 32 bit può allocare fino a 1577 MiB:

[C: scratch]> java -Xmx1600M MaxMemory
Si è verificato un errore durante l'inizializzazione della VM
Impossibile riservare spazio sufficiente per l'heap degli oggetti
Impossibile creare la Java virtual machine.
[C: scratch]> java -Xmx1590M MaxMemory
Memoria totale: 2031616 (1,9375 MiB)
Memoria massima: 1654456320 (1577.8125 MiB)
Memoria libera: 1840872 (1.75559234619 MiB)
[C: zero]>

Considerando che con una JVM a 64 bit sullo stesso sistema operativo, ovviamente è molto più alto (circa 3 TiB)

[C: scratch]> java -Xmx3560G MaxMemory
Si è verificato un errore durante l'inizializzazione della VM
Impossibile riservare spazio sufficiente per l'heap degli oggetti
[C: scratch]> java -Xmx3550G MaxMemory
Memoria totale: 94240768 (89,875 MiB)
Memoria massima: 3388252028928 (3184151.84297 MiB)
Memoria libera: 93747752 (89,4048233032 MiB)
[C: zero]>

Come altri hanno già detto, dipende dal sistema operativo.

• Per Windows a 32 bit: sarà <2 GB (il libro sugli interni di Windows dice 2 GB per i processi utente)
• Per BSD / Linux a 32 bit: <3 GB (dal Devil Book)
• Per MacOS X a 32 bit: <4 GB (dal libro degli interni di Mac OS X )
• Non sei sicuro di Solaris a 32 bit, prova il codice sopra e faccelo sapere.

Per un sistema operativo host a 64 bit, se la JVM è a 32 bit, dipenderà comunque, molto probabilmente come sopra come dimostrato.

- AGGIORNAMENTO 20110905 : volevo solo segnalare alcune altre osservazioni / dettagli:

• L'hardware su cui l'ho eseguito era a 64 bit con 6 GB di RAM effettiva installata. Il sistema operativo era Windows 7 Enterprise, 64 bit
• La quantità effettiva Runtime.MaxMemoryche può essere allocata dipende anche dal working set del sistema operativo . Una volta l'ho eseguito mentre avevo anche VirtualBox in esecuzione e ho scoperto che non potevo avviare con successo HotSpot JVM -Xmx1590Me dovevo ridurlo . Ciò implica anche che potresti ottenere più di 1590 M a seconda delle dimensioni del set di lavoro al momento (anche se continuo a mantenerlo sotto 2 GiB per 32 bit a causa del design di Windows)

Non si specifica quale sistema operativo.

In Windows (per la mia applicazione, un'applicazione di gestione del rischio di lunga durata) abbiamo osservato che non potevamo andare oltre 1280 MB su Windows a 32 bit. Dubito che eseguire una JVM a 32 bit sotto 64 bit farebbe la differenza.

Abbiamo portato l'app su Linux e stiamo eseguendo una JVM a 32 bit su hardware a 64 bit e abbiamo avuto una VM da 2,2 GB in esecuzione abbastanza facilmente.

Il problema più grande che potresti avere è GC, a seconda di cosa stai utilizzando la memoria.

Da 4.1.2 Dimensionamento heap :

"Per un modello di processo a 32 bit, la dimensione massima dell'indirizzo virtuale del processo è in genere 4 GB, sebbene alcuni sistemi operativi la limitino a 2 GB o 3 GB. La dimensione massima dell'heap è in genere -Xmx3800m (1600m) per i limiti di 2 GB ), sebbene la limitazione effettiva dipenda dall'applicazione. Per i modelli di processo a 64 bit, il massimo è essenzialmente illimitato. "

Ho trovato una risposta abbastanza buona qui: memoria massima Java su Windows XP .

Di recente abbiamo avuto qualche esperienza con questo. Recentemente siamo passati da Solaris (x86-64 Versione 5.10) a Linux (RedHat x86-64) e ci siamo resi conto che abbiamo meno memoria disponibile per un processo JVM a 32 bit su Linux rispetto a Solaris.

Per Solaris questo si aggira quasi intorno a 4 GB (http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit).

Abbiamo eseguito la nostra app con -Xms2560m -Xmx2560m -XX: MaxPermSize = 512m -XX: PermSize = 512m senza problemi su Solaris negli ultimi due anni. Ho provato a spostarlo su Linux e abbiamo avuto problemi con errori casuali di memoria insufficiente all'avvio. È stato possibile avviarlo in modo coerente solo su -Xms2300 -Xmx2300 . Quindi siamo stati avvisati di questo dall'assistenza.

Un processo a 32 bit su Linux ha uno spazio di indirizzi indirizzabile massimo di 3 GB (3072 MB) mentre su Solaris è il pieno di 4 GB (4096 MB).

Le limitazioni di una JVM a 32 bit su un sistema operativo a 64 bit saranno esattamente le stesse delle limitazioni di una JVM a 32 bit su un sistema operativo a 32 bit. Dopo tutto, la JVM a 32 bit verrà eseguita in una macchina virtuale a 32 bit (nel senso della virtualizzazione), quindi non saprà che è in esecuzione su un sistema operativo / macchina a 64 bit.

L'unico vantaggio dell'esecuzione di una JVM a 32 bit su un sistema operativo a 64 bit rispetto a un sistema operativo a 32 bit è che puoi avere più memoria fisica e quindi incontrerai lo scambio / paging meno frequentemente. Tuttavia, questo vantaggio si realizza pienamente solo quando si hanno più processi.

Quanto al motivo per cui viene utilizzata una JVM a 32 bit invece di una a 64 bit, il motivo non è tecnico ma piuttosto amministrativo / burocratico ...

Quando lavoravo per BEA, abbiamo scoperto che l'applicazione media in realtà funzionava più lentamente in una JVM a 64 bit, rispetto a quando era in esecuzione in una JVM a 32 bit. In alcuni casi, il calo delle prestazioni è stato fino al 25% più lento. Quindi, a meno che la tua applicazione non abbia davvero bisogno di tutta quella memoria extra, faresti meglio a configurare più server a 32 bit.

Per quanto ricordo, le tre giustificazioni tecniche più comuni per l'utilizzo di un 64 bit in cui si è imbattuto il personale dei servizi professionali BEA erano:

1. L'applicazione stava manipolando più immagini enormi,
2. L'applicazione stava eseguendo un enorme scricchiolio di numeri,
3. L'applicazione presentava una perdita di memoria, il cliente era il protagonista di un contratto governativo e non volevano prendersi il tempo e le spese per rintracciare la perdita di memoria. (L'uso di un enorme mucchio di memoria aumenterebbe l'MTBF e il primo verrebbe comunque pagato)

.

JROCKIT JVM attualmente di proprietà di Oracle supporta l'utilizzo dell'heap non contiguo, consentendo così alla JVM a 32 bit di accedere a più di 3,8 GB di memoria quando la JVM è in esecuzione su un sistema operativo Windows a 64 bit. (2,8 GB quando si esegue su un sistema operativo a 32 bit).

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

La JVM può essere scaricata gratuitamente (è richiesta la registrazione) all'indirizzo

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

Ecco alcuni test con Solaris e Linux a 64 bit

Solaris 10 - SPARC - T5220 macchina con 32 GB di RAM (e circa 9 GB liberi)

$ 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: Apparentemente Java non alloca molta memoria effettiva con l'avvio. Sembrava che ci volessero solo circa 100 MB per istanza avviata (ho iniziato 10)

Solaris 10 - x86 - VMWare VM con 8 GB di RAM (circa 3 GB liberi *)

La RAM libera da 3 GB non è proprio vera. C'è una grande porzione di RAM che le cache ZFS usano, ma non ho accesso root per controllare esattamente quanto

$ 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 di RAM (circa 3,8 GB utilizzati - 200 MB nei buffer e 3,1 GB nelle cache, quindi circa 3 GB liberi)

$ 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

Stessa macchina utilizzando 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

Dovrebbe essere molto meglio

Per una JVM a 32 bit in esecuzione su un host a 64 bit, immagino che ciò che rimane per l'heap sarà lo spazio virtuale non frammentato disponibile dopo la JVM, le sue DLL e qualsiasi materiale di compatibilità a 32 bit del sistema operativo è stato caricato. Come ipotesi selvaggia, penserei che 3 GB dovrebbero essere possibili, ma quanto sia migliore dipende da quanto bene stai andando nella terra host a 32 bit.

Inoltre, anche se potessi creare un enorme mucchio di 3 GB, potresti non volerlo, poiché ciò renderà potenzialmente fastidiose le pause GC. Alcune persone eseguono semplicemente più JVM per utilizzare la memoria extra piuttosto che una gigante. Immagino che in questo momento stiano ottimizzando le JVM per funzionare meglio con cumuli giganti.

È un po 'difficile sapere esattamente quanto meglio puoi fare. Immagino che la tua situazione a 32 bit possa essere facilmente determinata mediante esperimento. È certamente difficile prevedere in modo astratto, poiché molte cose vi influiscono, in particolare perché lo spazio virtuale disponibile su host a 32 bit è piuttosto limitato .. L'heap deve esistere nella memoria virtuale contigua, quindi la frammentazione dello spazio degli indirizzi per dll e l'uso interno dello spazio degli indirizzi da parte del kernel del sistema operativo determineranno la gamma di possibili allocazioni.

Il sistema operativo utilizzerà parte dello spazio degli indirizzi per mappare i dispositivi HW e le proprie allocazioni dinamiche. Anche se questa memoria non è mappata nello spazio degli indirizzi del processo java, il kernel del sistema operativo non può accedervi e il tuo spazio degli indirizzi contemporaneamente, quindi limiterà la dimensione dello spazio virtuale di qualsiasi programma.

Il caricamento delle DLL dipende dall'implementazione e dal rilascio della JVM. Il caricamento del kernel del sistema operativo dipende da un numero enorme di cose, dal rilascio, dall'HW, da quante cose ha mappato finora dall'ultimo riavvio, chissà ...

In sintesi

Scommetto che ottieni 1-2 GB a 32 bit e circa 3 a 64 bit, quindi un miglioramento complessivo di circa 2x .

Su Solaris il limite è stato di circa 3,5 GB da Solaris 2.5. (circa 10 anni fa)

Avevo gli stessi problemi con la JVM utilizzata da App Inventor per Android Blocks Editor. Imposta l'heap a 925 m max. Questo non è sufficiente ma non sono riuscito a impostarlo a più di 1200 m circa, a seconda di vari fattori casuali sulla mia macchina.

Ho scaricato Nightly, il browser beta a 64 bit da Firefox, e anche la versione JAVA 7 a 64 bit.

Non ho ancora trovato il mio nuovo limite di heap, ma ho appena aperto una JVM con una dimensione di heap di 5900 m . Nessun problema!

Sto eseguendo Win 7 64 bit Ultimate su una macchina con 24 GB di RAM.

Ho provato a impostare la dimensione dell'heap fino a 2200M su una macchina Linux a 32 bit e JVM ha funzionato bene. La JVM non si è avviata quando l'ho impostata su 2300M.

Questo è un tuning pesante, ma puoi ottenere un mucchio di 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 altro punto qui per l'hotspot JVM a 32 bit: - la capacità dell'heap nativo = 4 Gig - Java Heap - PermGen;

Può diventare particolarmente complicato per JVM a 32 bit poiché Java Heap e Heap nativo sono in competizione. Più grande è il tuo Java Heap, più piccolo è l'Heap nativo. Il tentativo di configurare un heap di grandi dimensioni per una VM a 32 bit, ad esempio .2,5 GB + aumenta il rischio di OutOfMemoryError nativo a seconda dell'impronta delle applicazioni, del numero di thread, ecc.

La limitazione deriva anche dal fatto che per una 32 bitVM, la heapstessa deve iniziare dall'indirizzo zero se vuoi tutte quelle4GB .

Pensaci, se vuoi fare riferimento a qualcosa tramite:

0000....0001

cioè: un riferimento che ha questa particolare rappresentazione di bit, significa che stai tentando di accedere alla prima memoria dall'heap. Affinché ciò sia possibile, l'heap deve iniziare dall'indirizzo zero. Ma ciò non accade mai, inizia con un offset da zero:

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

Poiché l'heap non inizia mai dall'indirizzo zero in un OS, ci sono un bel po 'di bit che non vengono mai utilizzati da un 32riferimento di bit, e come tale l'heap a cui è possibile fare riferimento è inferiore.

Teorico 4 GB, ma in pratica (per IBM JVM):

Win 2k8 64, IBM Websphere Application Server 8.5.5 32 bit

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 bit

[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.