64ビットJVMで可能な最大のヒープサイズはどれくらいですか？
32ビットシステムで-Xmxで設定できる理論上の最大ヒープ値は、もちろん2^32バイトですが、通常（参照： 最大JVMヒープサイズの理解-32ビットと64ビット ）4GBをすべて使用することはできません。
64ビットマシン上の64ビットOSで実行されている64ビットJVMの場合、理論上の制限2^64バイトまたは16エクサバイト以外の制限はありますか？
さまざまな理由（主にガベージコレクション）のために、過度に大きいヒープはwiseではないかもしれませんが、テラバイトのRAMを搭載したサーバーについて読むと、 possibleとは何なのかと思います。
32ビット参照を使用する場合、ヒープは32 GBに制限されます。
ただし、64ビット参照を使用する場合、32ビットJVMと同様に、サイズはOSによって制限される可能性があります。例えばWindows 32ビットでは、これは1.2〜1.5 GBです。
注：JVMヒープは、理想的には1つのNUMA領域内のメインメモリに収まるようにする必要があります。それは約1 TBより大きいマシンで。JVMがNUMAリージョンにまたがる場合、特にメモリアクセスとGCに時間がかかります。JVMヒープがスワップを開始すると、GCに数時間かかることがあります。または、スワップドライブをスラッシングするため、マシンを使用できなくします。
注：ヒープで32ビット参照を使用している場合でも、大きなダイレクトメモリおよびメモリマップサイズにアクセスできます。つまり、32 GBを大きく超えて使用します。
圧縮されたoopは、マネージポインター（JVMのすべてではないが多くの場所）を32倍の値として表します。8倍にスケーリングし、参照するオブジェクトを見つけるために64ビットのベースアドレスに追加する必要があります。これにより、アプリケーションは最大40億個のオブジェクト（バイトではない）、または最大約32Gbのヒープサイズに対応できます。同時に、データ構造のコンパクトさはILP32モードと競合します。
Windowsではプロセスごとにメモリ制限が課されます。各バージョンのメモリ容量を確認できます here
見る：
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は、圧縮されたOOPのvmargsで受け入れられます。
64ビットマシン上の64ビットOSで実行される64ビットJVMの場合、理論上の制限である2 ^ 64バイトまたは16エクサバイト以外に制限はありますか？
ハードウェアの制限も考慮する必要があります。ポインタは64ビットですが、現在のCPUは 2 ^ 64バイト未満の仮想メモリ のみをアドレス指定できます。
圧縮されていないポインターを使用すると、ホットスポットJVMはヒープ用に仮想アドレス空間の連続したチャンクを必要とします。したがって、ハードウェアに続く2番目のハードルは、このような大きなチャンクを提供するオペレーティングシステムであり、すべてのOSがこれをサポートしているわけではありません。
そして3つ目は実用性です。仮想メモリがそれほど多くても、CPUがその物理メモリをサポートしているわけではなく、物理メモリがなければスワップが発生することになります。これは、GCが一般的に大きな部分に触れる必要があるため、JVMのパフォーマンスに悪影響を及ぼしますヒープの。
他の回答が圧縮OOPに言及しているように、オブジェクトのアライメントを8バイトより大きくすることにより、圧縮OOPの制限を 2GBを超えて増加 にできます。