32ビットOSの最大アドレス可能メモリサイズは4GBであり、JVMの最大ヒープサイズは、予約可能な連続する空きメモリの量に依存するため、32ビットOSの最大ヒープサイズについては問題ではありません。
私は、64ビットOSで実行されている32ビットJVMの最大（理論上および実際に達成可能な）ヒープサイズを知ることに興味があります。基本的に、私はSOに関する関連する質問の数字と同様の答えを見ています。
64ビットのJVMではなく32ビットのJVMが使用される理由については、その理由は技術的ではなく、管理/官僚的です。64ビットJVMを本番環境にインストールするのはおそらく遅すぎます。
回答:
単一の大きなメモリチャンクがあり、生のポインターを使用することを期待する32ビットJVMは、4 Gbを超えることはできません（これは、ポインターにも適用される32ビットの制限であるため）。これには、Sunと-確かに-IBMの実装も含まれます。JRockitなどの32ビット実装で大容量メモリオプションがあるかどうかはわかりません。
この制限に達すると予想される場合は、本番環境用の64ビットJVMを検証する並列トラックを開始して、32ビット環境が故障した場合に備えておくことを強く検討する必要があります。さもなければ、あなたはプレッシャーの下でその仕事をしなければならないでしょう、それは決して良くありません。
2014-05-15を編集：Oracle FAQ：
32ビットJVMの理論上の最大ヒープ制限は4Gです。利用可能なスワップ、カーネルアドレススペースの使用、メモリの断片化、VMオーバーヘッドなどのさまざまな追加の制約により、実際には制限ははるかに低くなる可能性があります。最新の32ビットWindowsシステムでは、最大ヒープサイズの範囲は1.4Gから1.6Gです。32ビットのSolarisカーネルでは、アドレス空間は2Gに制限されています。32ビットVMを実行する64ビットオペレーティングシステムでは、最大ヒープサイズが大きくなる可能性があり、多くのSolarisシステムでは4Gに近づきます。
（http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit）
あなたはJavaランタイムに尋ねることができます：
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)");
}
}これは、デフォルトのヒープ割り当てに基づいて「最大メモリ」を報告します。したがって、まだ-Xmx（HotSpotで）遊ぶ必要があります。Windows 7 Enterprise 64ビットで実行している場合、32ビットの HotSpot JVMは最大1577MiBを割り当てることができることがわかりました。
[C：スクラッチ]> java -Xmx1600M MaxMemory VMの初期化中にエラーが発生しました オブジェクトヒープ用に十分なスペースを予約できませんでした Java仮想マシンを作成できませんでした。 [C：scratch]> java -Xmx1590M MaxMemory 合計メモリ：2031616（1.9375 MiB） 最大メモリー：1654456320（1577.8125 MiB） 空きメモリ：1840872（1.75559234619 MiB） [C：スクラッチ]>
とのに対し、64ビット JVM同じOS上で、もちろんそれははるかに高い（3TiB程度）です
[C：scratch]> java -Xmx3560G MaxMemory VMの初期化中にエラーが発生しました オブジェクトヒープ用に十分なスペースを予約できませんでした [C：スクラッチ]> java -Xmx3550G MaxMemory 合計メモリ：94240768（89.875 MiB） 最大メモリー：3388252028928（3184151.84297 MiB） 空きメモリ：93747752（89.4048233032 MiB） [C：スクラッチ]>
他の人がすでに述べたように、それはOSに依存します。
64ビットのホストOSの場合、JVMが32ビットの場合でも、ほとんどの場合は上記のように依存します。
-UPDATE 20110905：私は他の観察/詳細を指摘したかっただけです：
Runtime.MaxMemory割り当てることができる実際の量も、オペレーティングシステムのワーキングセットによって異なります。VirtualBoxも実行しているときにこれを実行したところ、HotSpot JVMを正常に起動できず、-Xmx1590M小さくする必要がありました。これは、そのときのワーキングセットのサイズによっては、1590Mを超える可能性があることも意味します（ただし、Windowsの設計により、32ビットでは2GiB未満に維持します）。どの OSを指定する必要はありません。
Windows（私のアプリケーションの場合-長時間実行されるリスク管理アプリケーション）では、Windows 32ビットで1280MBを超えることはできないことがわかりました。64ビットで32ビットのJVMを実行しても違いが出るとは思いません。
アプリをLinuxに移植し、64ビットのハードウェアで32ビットのJVMを実行しており、2.2GBのVMを簡単に実行できました。
あなたが持つかもしれない最大の問題は、あなたがメモリを何のために使っているかによるGCです。
「32ビットプロセスモデルの場合、プロセスの最大仮想アドレスサイズは通常4 GBですが、オペレーティングシステムによっては2 GBまたは3 GBに制限されています。最大ヒープサイズは通常2 GB制限の場合-Xmx3800m（1600m）です。 ）、ただし、実際の制限はアプリケーションに依存します。64ビットプロセスモデルの場合、最大数は基本的に無制限です。」
ここでかなり良い答えが見つかりました：Windows XP上のJava最大メモリ。
私たちは最近これについていくらか経験をしました。最近、Solaris（x86-64バージョン5.10）からLinux（RedHat x86-64）に移植しましたが、Linux上の32ビットJVMプロセスで使用できるメモリはSolarisよりも少ないことに気付きました。
Solarisの場合、これはほぼ4GBになります（http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit）。
-Xms2560m -Xmx2560m -XX：MaxPermSize = 512m -XX：PermSize = 512mを使用してアプリを実行したところ、Solarisで過去2年間問題は発生しませんでした。Linuxに移動しようとしたところ、起動時にランダムメモリ不足エラーが発生しました。-Xms2300 -Xmx2300で一貫して起動するだけでした。それから私達はサポートによってこれについて助言されました。
Linuxの32ビットプロセスの最大アドレス可能アドレススペースは3GB（3072MB）ですが、Solarisではフル4GB（4096MB）です。
64ビットOSでの32ビットJVMの制限は、32ビットOSでの32ビットJVMの制限とまったく同じです。結局のところ、32ビットのJVMは（仮想化の意味で）32ビットの仮想マシンで実行されるため、64ビットのOS /マシンで実行されていることがわかりません。
32ビットJVMを64ビットOSで実行する場合と32ビットOSで実行する場合の利点の1つは、より多くの物理メモリを使用できるため、スワッピング/ページングの頻度が少なくなることです。ただし、この利点は、複数のプロセスがある場合にのみ完全に実現されます。
64ビットのJVMの代わりに32ビットのJVMが使用される理由については、その理由は技術的ではなく、管理/官僚的です...
私がBEAで働いていたとき、平均的なアプリケーションは実際には64ビットJVMで実行すると遅くなり、32ビットJVMで実行すると遅くなりました。場合によっては、パフォーマンスへの影響が25％も遅くなっていました。したがって、アプリケーションが実際にそのようなすべての追加のメモリを必要としない限り、より多くの32ビットサーバーをセットアップする方がよいでしょう。
私が覚えているように、BEAプロフェッショナルサービス担当者が遭遇した64ビットを使用するための最も一般的な3つの技術的正当化は次のとおりです。
。
現在Oracleが所有しているJROCKIT JVMは非連続ヒープ使用をサポートしているため、JVMが64ビットWindows OSで実行されている場合、32ビットJVMは3.8 GBを超えるメモリにアクセスできます。（32ビットOSで実行する場合は2.8 GB）。
http://blogs.oracle.com/jrockit/entry/how_to_get_almost_3_gb_heap_on_windows
JVMは無料でダウンロードできます（登録が必要です）。
http://www.oracle.com/technetwork/middleware/jrockit/downloads/index.html
以下は、SolarisおよびLinux 64ビットでのテストです。
$ 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ところで、どうやらJavaは起動時に実際のメモリをあまり割り当てません。起動したインスタンスごとに約100 MBしかかからないようです（10を起動しました）。
3 GBの空きRAMは実際には当てはまりません。ZFSキャッシュが使用するRAMの大きな塊がありますが、どれだけ正確にチェックするためのrootアクセス権がありません
$ 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$ 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$ 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 kB64ビットホストで実行されている32ビットJVMの場合、JVM、独自のDLL、およびOSの32ビット互換のものをロードした後、ヒープに残されたものは、断片化されていない仮想スペースになります。おおまかな推測として、3GBは可能だと思いますが、それがどれだけ良いかは、32ビットホストランドでのパフォーマンスに依存します。
また、3 GBの巨大なヒープを作成できたとしても、GCの一時停止が問題になる可能性があるため、作成したくない場合があります。一部の人々は、1つの巨大なメモリではなく、より多くのJVMを実行して追加のメモリを使用します。巨大なヒープでよりうまく機能するように、JVMを現在調整していると思います。
どれだけ良いことができるかを正確に知るのは少し難しいです。32ビットの状況は実験で簡単に判断できると思います。特に32ビットホストで使用できる仮想空間はかなり制限されているため、多くのことが要因として抽象的に予測することは確かに困難です。ヒープは連続した仮想メモリに存在する必要があるため、アドレス空間の断片化はDLLとOSカーネルによるアドレススペースの内部使用により、可能な割り当ての範囲が決まります。
OSはHWデバイスのマッピングにアドレス空間の一部を使用し、独自の動的割り当てを行います。このメモリはJavaプロセスのアドレス空間にマッピングされていませんが、OSカーネルはメモリとアドレス空間に同時にアクセスできないため、プログラムの仮想空間のサイズが制限されます。
DLLのロードは、JVMの実装とリリースに依存します。OSカーネルのロードは、リリース、ハードウェア、最後の再起動以降にマッピングされたものなど、非常に多くのことに依存しています...
32ビットランドで1〜2 GB、64ビットランドで約3になるため、全体的に約2倍向上します。
App Block for Android Blocks Editorが使用するJVMで同じ問題が発生していました。ヒープを最大925mに設定します。これでは十分ではありませんが、マシンのさまざまなランダム要因によっては、約1200mを超えて設定することはできませんでした。
Firefoxからベータ版の64ビットブラウザであるNightlyと、JAVA 7 64ビット版をダウンロードしました。
新しいヒープ制限はまだ見つかりませんが、ヒープサイズが5900mの JVMを開いたところです。問題ない！
24GBのRAMを搭載したマシンでWin 7 64ビットUltimateを実行しています。
32ビットLinuxマシンでヒープサイズを最大2200Mに設定してみましたが、JVMは正常に機能しました。JVMを2300Mに設定しても起動しませんでした。
制限は、32 bitVMの場合、heapそれらすべてが必要な場合、VM 自体がアドレス0から開始する必要があることにも起因し4GBます。
次の方法で何かを参照したい場合は、それについて考えてください。
0000....0001つまり、この特定のビット表現を持つ参照は、ヒープから最初のメモリにアクセスしようとしていることを意味します。そのためには、ヒープはアドレス0から開始する必要があります。しかし、それは決して起こりません、それはゼロからのあるオフセットで始まります：
| .... .... {heap_start .... heap_end} ... |
--> (this can't be referenced) <--ヒープはのアドレス0から始まるOSことは決してないため、32ビット参照から使用されることのないかなりの数のビットが存在するため、参照できるヒープは低くなります。
理論上の4GBですが、実際には（IBM JVMの場合）：
Win 2k8 64、IBM Websphere Application Server 8.5.5 32ビット
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ビット
[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.