java没有正确保留巨大的初始堆大小
我在一台有512 by (由几个AMD Opteron 6212 CPU寻址)的机器上工作。目前大约有300 is的空闲内存。通过运行以下命令运行大型java计算
java path/to/myApp -Xms280g -Xmx280g > output.txt应该让Java立即保留280 if，如果失败就会出错。奇怪的是，没有发生错误，但top只显示了30.4‘t的内存使用量，但它没有崩溃。这怎么会发生呢？如果不能分配初始堆大小，java不是应该崩溃吗？
实际上，在达到280 GC之前，一旦30.4 GC空间已满，我就会收到OutOfMemory/Java堆空间/GC开销限制错误。以250 or或300 or运行会产生类似的30.3 or~30.4 or的限制。我在Gentoo Linux上运行OpenJDK 64位服务器虚拟机和OpenJDK运行时环境(IcedTea6)，并且有大量的空闲内存(超过300 64)。
回答 3
Stack Overflow用户
发布于 2014-06-02 04:45:01
参数的顺序不正确。您将-Xms280g -Xmx280g作为参数传递给您自己的程序，而不是传递给JVM。正确的做法是：
java -Xms280g -Xmx280g path/to/myApp
Stack Overflow用户
发布于 2014-05-28 06:41:34
尝试在命令行中添加-d64参数
java -d64 path/to/myApp -Xms280g -Xmx280g > output.txtStack Overflow用户
发布于 2014-06-02 14:36:44
因此，您将达到大约32 GB的限制。当甲骨文谈到Compressed oops in the Hotspot JVM时，它也提到了32 it。
然而，在LP64系统上，任何给定运行的堆可能必须是相应ILP32系统的1.5倍左右(假设运行同时适合两种模式)。这是因为托管指针的大小扩大了。内存很便宜，但是现在带宽和缓存供不应求，所以为了超过4 4Gb的限制而大幅增加堆的大小是很痛苦的。
(此外，在x86芯片上，ILP32模式提供的可用寄存器是LP64模式的一半。SPARC不会受到这种影响；RISC芯片一开始有很多寄存器，只是将它们扩展为LP64模式。)
压缩的oops将托管指针(在JVM中的许多位置，但不是所有位置)表示为32位值，必须将其缩放为8的因子，并添加到64位基址，以查找它们所引用的对象。这允许应用程序寻址多达40亿个对象(非字节)，or a heap size of up to about 32Gb.
https://stackoverflow.com/questions/23860364
复制相似问题
腾讯云开发者
