-Xmx32ビットシステムで設定できる理論上の最大ヒープ値はもちろん2^32バイトですが、通常（最大JVMヒープサイズの理解-32ビットと64ビットを参照）4GBすべてを使用することはできません。
64ビットマシンの64ビットOSで実行されている64ビットJVMの場合、理論上の2^64バイト数または16エクサバイトの制限以外に制限はありますか？
さまざまな理由（主にガベージコレクション）で、過度に大きなヒープは賢明ではないかもしれないことを私は知っていますが、テラバイトのRAMを備えたサーバーについて読んだことを考えると、何が可能か疑問に思います。
32ビット参照を使用する場合、ヒープは32GBに制限されています。
ただし、64ビット参照を使用する場合は、32ビットJVMの場合と同様に、サイズがOSによって制限される可能性があります。たとえば、Windows 32ビットの場合、これは1.2〜1.5GBです。
注：JVMヒープをメインメモリに、理想的には1つのNUMAリージョン内に収める必要があります。これは、より大きなマシンでは約1TBです。JVMがNUMAリージョンにまたがる場合、メモリアクセスと特にGCははるかに長くかかります。JVMヒープがスワッピングを開始すると、GCに数時間かかる場合があります。また、スワップドライブがクラッシュするため、マシンが使用できなくなる場合もあります。
注：ヒープで32ビット参照を使用している場合でも、大きなダイレクトメモリとメモリマップサイズにアクセスできます。つまり、32GBをはるかに超えて使用します。
圧縮されたoopsは、マネージポインター（JVMのすべてではありませんが多くの場所）を32ビット値として表します。32ビット値は、8倍にスケーリングし、参照するオブジェクトを見つけるために64ビットベースアドレスに追加する必要があります。これにより、アプリケーションは最大40億のオブジェクト（バイトではない）、または最大約32Gbのヒープサイズをアドレス指定できます。同時に、データ構造のコンパクトさはILP32モードと競合します。
答えは明らかにJVMの実装に依存します。アズールは彼らのJVMが
...を1/2テラバイト以上のメモリに拡張できます
「スケーリングできる」とは、「まったく実行されない」ではなく、「十分に実行されている」ことを意味するように見えます。
Windowsはプロセスごとにメモリ制限を課します。ここで、各バージョンのメモリ制限を確認できます。
見る：
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
私が試し-Xmx32255Mたのは、圧縮されたoopsのvmargsに受け入れられました。
64ビットマシンの64ビットOSで実行されている64ビットJVMの場合、2 ^ 64バイトまたは16エクサバイトの理論上の制限以外に制限はありますか？
また、ハードウェアの制限も考慮する必要があります。ポインタは64ビットである可能性がありますが、現在のCPUは2^64バイト未満の仮想メモリしかアドレス指定できません。
圧縮されていないポインタを使用する場合、ホットスポットJVMは、ヒープ用に仮想アドレス空間の連続チャンクを必要とします。したがって、ハードウェアに続く2番目のハードルは、そのような大きなチャンクを提供するオペレーティングシステムであり、すべてのOSがこれをサポートしているわけではありません。
そして3つ目は実用性です。たとえそれだけの仮想メモリを使用できるとしても、CPUがそれほど多くの物理メモリをサポートしているわけではなく、物理メモリがないとスワッピングが発生し、GCは一般に大部分に触れる必要があるため、JVMのパフォーマンスに悪影響を及ぼします。ヒープの。
他の回答が圧縮されたoopsに言及しているように：オブジェクトの配置を8バイトより高くすることにより、圧縮されたoopsの制限を32GBを超えて増やすことができます
理論的にはすべてが可能ですが、実際には、予想よりもはるかに少ない数値が見つかります。私はサーバー上の巨大なスペースに頻繁に対処しようとしてきましたが、サーバーに大量のメモリを搭載できる場合でも、CPUが実際に対処するのに十分な速度ではないという理由だけで、ほとんどのソフトウェアが実際のシナリオで実際に対処できないことに驚きました。 。なぜあなたは正しいと言いますか？！。私が取り組んできたすべての巨大なマシンの終わりのない崩壊であるタイミング。だから私は、あなたができるという理由だけで膨大な量に対処することによって行き過ぎないことをお勧めしますが、あなたが使用できると思うものを使用してください。多くの場合、実際の値は予想よりもはるかに低くなります。もちろん、私たち以外の人は実際に自宅でhp 9000システムを使用しており、ほとんどの人は実際に自宅のシステムの容量に近づくでしょう。たとえば、ほとんどのユーザーは、システムに16Gbを超えるメモリを持っていません。もちろん、カジュアルゲーマーの中には、月に1回、ワークステーションを使ってゲームをする人もいますが、それはごくわずかな割合だと思います。つまり、地球に降りてくるということは、8 Gb64ビットシステムでヒープスペースを512mb以下でアドレス指定することを意味します。または、船外に出る場合は1Gbを試してください。私は、これらの数字でさえ、純粋にやり過ぎだと確信しています。私はゲーム中のメモリ使用量を常に監視して、アドレス指定によって違いが生じるかどうかを確認しましたが、はるかに低い値または大きい値にアドレス指定した場合、まったく違いに気づきませんでした。サーバー/ワークステーションでも、値をどれだけ大きく設定しても、パフォーマンスに目に見える変化はありませんでした。これは、一部のjaveユーザーがアドレス指定されたより多くのスペースを利用できる可能性があるということではありません。しかし、これまでのところ、これほど多くを必要とするアプリケーションは見たことがありません。もちろん、Javaインスタンスが動作するのに十分なヒープスペースを使い果たした場合、パフォーマンスにわずかな違いがあると思います。これまでのところ、私はそれをまったく見つけていませんが、実際にインストールされたメモリが不足していると、ヒープスペースを設定しすぎるとパフォーマンスが瞬時に低下します。4 Gbシステムを使用している場合、ヒープスペースがすぐに不足し、システム内で実際には空きがないスペースに対処しすぎて、OSが不足分を補うためにドライブスペースに対処し始めるため、エラーと速度低下が発生します。したがって、スワップを開始します。ただし、実際にインストールされているメモリが不足していると、ヒープスペースを設定しすぎるとパフォーマンスが瞬時に低下します。4 Gbシステムを使用している場合、ヒープスペースがすぐに不足し、システム内で実際には空きがないスペースに対処しすぎて、OSが不足分を補うためにドライブスペースに対処し始めるため、エラーと速度低下が発生します。したがって、スワップを開始します。ただし、実際にインストールされているメモリが不足していると、ヒープスペースを設定しすぎるとパフォーマンスが瞬時に低下します。4 Gbシステムを使用している場合、ヒープスペースがすぐに不足し、システム内で実際には空きがないスペースに対処しすぎて、OSが不足分を補うためにドライブスペースに対処し始めるため、エラーと速度低下が発生します。したがって、スワップを開始します。