簡體 English 中英

JVM是32 OR 64 BIT？

[英]32 OR 64 BIT for the JVM?

原文 2015-01-06 06:09:05 0 8 java/ performance/ jvm

在這里讀這本書的時候。

我可以看到以下部分，其中說：

32或64位？ 如果您有32位操作系統，則必須使用32位版本的JVM。 如果您有64位操作系統，則可以選擇使用32位或64位版本的Java。 不要以為僅僅因為您擁有64位操作系統，您還必須使用64位版本的Java。

如果堆的大小小於約3 GB，則32位版本的Java將更快並且占用空間更小。 這是因為JVM中的內存引用只有32位，操作這些內存引用比操作64位引用要便宜（即使你有64位CPU）。 32位引用也使用較少的內存。

第8章討論了壓縮oops，這是JVM甚至可以在64位JVM中使用32位地址的一種方式。 但是，即使進行了這種優化，64位JVM的占用空間也會更大，因為它使用的本機代碼仍然具有64位地址。

32位JVM的缺點是總進程大小必須小於4GB（在某些版本的Windows上為3GB，在某些舊版本的Linux上為3.5GB）。 這包括堆，permgen以及JVM使用的本機代碼和本機內存。 在32位JVM上廣泛使用長變量或雙變量的程序會更慢，因為它們不能使用CPU的64位寄存器，盡管這是一種非常特殊的情況。

適合32位地址空間的程序在32位JVM中的運行速度比類似配置的64位JVM快5％到20％。 例如，本章前面討論的庫存批處理程序在桌面上運行32位JVM時速度提高了20％。

這些行說明，對於較小的堆大小（小於3GB），32位會更快。 如果這是真的，我想知道它背后的原因，是什么讓32位JVM更快？

8 個解決方案

我對作者聲稱使用32位版本的JVM會使性能提高5％到20％持懷疑態度。 但是，我不太使用Java，所以我不確定。 但為了調查這一說法，我查看了SPEC的一些結果。

我搜索了SPECjEnterprise2010的結果，x86-64架構的最高分是一個使用64位版本JVM的Oracle系統。

我還查看了SPECjvm2008，以防這些較小的工作負載可能受益於32位架構。 但同樣來自華為的最佳性能x86-64系統使用的是64位版本的JVM。

如果32位版本的JVM確實更好，我希望人們提交他們的SPEC結果會在調整他們的工作負載時選擇（但我可能是錯的）。

我不懷疑有一些工作負載，其中32位版本的JVM將勝過64位版本。 正如其他人已經注意到它為地址使用更多內存。 但是，x86-64架構有更多可用的寄存器，我懷疑64位操作模式是大多數優化工作的重點。

系統性能有很多組件，我認為32位版本的JVM不一定會勝過64位版本（對於這一點而言，這只會對CPU綁定工作負載產生影響）。 我要說如果你在性能調優過程中達到這一點，你會想要檢查自己的工作負載以獲得兩個不同的選項，並使用你自己的測試結果做出決定而不是假設使用32 -bit優於64位，因為根據經驗節省了地址的內存空間，因為還有其他因素可能比這更重要。

這更多是一般表現的問題。 如果你有一個最近的64位處理器和大量未使用的內存，使用JVM 32而不是JVM 64的唯一可能的增益是一些循環可以完全適合具有32位地址的高速緩存而不是64位那些導致較少的主存儲器使用32位JVM訪問。 我真的無法評估增益，但除非在非常特殊的情況下我懷疑它達到5％到20％ - 注意我只是懷疑，不確定......

但是，如果您使用的是資源有限的系統，最終因為您希望優化硬件並在其上運行許多虛擬機，32位JVM將使用遠遠少於64位的內存。 它將為其他應用程序和系統留下更多可用內存，從而避免交換並允許系統更好地緩存磁盤IO。

恕我直言，沒有一般規則。 我只會使用以下經驗法則：如果JVM 和所有其他應用程序運行時，系統仍有足夠的內存用於緩存IO，我會使用64位JVM，而相反的情況下使用32位JVM。

當然，只有Java應用程序本身不需要大量使用64位JVM的內存 - 並且最終在必要時向系統添加更多內存時才有意義，因為現在內存不是那么昂貴

沒有簡單的答案，最好的辦法是針對您的具體應用進行嘗試。 但是你應該記住，還有很多其他的選擇，例如關於JIT，垃圾收集算法，RAM限制，可能比建築選擇更大的影響，所以你必須在測量中包含這些。

如果您曾經問過這個問題，換句話說可以選擇，那就意味着您已經在具有32位模式的64位系統上運行（具有可接受的性能，即沒有軟件仿真），這很可能是AMD64 aka x86-64 。

在這樣的系統上，Oracle的JVM支持“壓縮oops”，這意味着只要最大堆不超過32 GB，就可以在Java堆中使用32位引用（如果確實如此，我懷疑使用32位是該應用程序的有效選擇）。 與32位JVM相比，它可能仍然消耗更多RAM，因為某些組件仍然需要使用64位指針，但這些通常不是應用程序的性能相關部分。

請注意，對於使用64位模式的AMD64 aka x86-64架構，不僅僅意味着更改指針大小。 注意只允許每個寄存器使用64位，它還有更多可用的寄存器。 它實際上是在同一芯片中實現的不同架構，並且取決於您的應用，使其可能是一個很大的改進。

但正如所說，用真實應用程序測試它是獲得正確答案的唯一有效方法。

如果您打算使用其中一個Oracle VM，那么問題就更多地轉向您是否要使用客戶端或服務器JIT，因為Oracle還沒有可用於任何64位CPU的客戶端JIT。

服務器VM可用於32位和64位CPU，x86 / AMD64 CPU上的服務器VM的性能差異相當小（根據我的經驗，它在Windows或Linux上低於+/- 5％），盡管64位VM通常需要大約20％的內存。

如果您的應用程序需要堆內存大小超過大約1.3GB，則必須使用64位服務器VM，因為來自Oracle的32位VM不會以大於此值的堆大小啟動（在Linux上，限制略高）。

客戶端JIT的主要優點是它具有更快的啟動時間。 使用此VM，您可以在不到100毫秒的時間內完成相當多的認真工作，而即使打開分層編譯，服務器VM也只需要一秒鍾即可開始。 客戶端VM還需要比服務器VM少得多的內存，並且可以在同一計算機上的多個VM實例之間形成類數據共享。

另一方面，服務器VM傾向於能夠以相當快的速度執行計算密集型代碼。 實際性能差異根據您執行的代碼而有很大差異，但可能介於約-10％和+ 200％之間。 通常，對於運行時間超過幾百毫秒的任何事物，它至少快30％。

您可以使用各種選項調整兩個JIT，使它們的行為更相似，但您仍然只能通過客戶端VM獲得快速啟動時間，並且只能通過服務器VM獲得最高的執行速度。

因此，當有足夠的可用內存並且不關心啟動時間損失時，我建議將64位服務器VM用於所有內容。 32位客戶端VM非常適合較小的GUI應用程序，但尤其適用於平均執行時間不到一秒的小型命令行工具，或者可能需要在同一台計算機上同時運行多次。

32位內存地址較小。 僅這一點可能會帶來更好的緩存，參考位置等。

32位地址更少的內存空間最大理論限制是4GB，但實際上它在Windows系統中是1.3GB。 您可以在Linux內核上解決更多（300到400 MB）的問題。 有關更多詳細信息，請使用http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit （堆空間內存）

64位使用更高的位來尋址。 所以整體內存消耗也更高。 可以選擇使用壓縮內存指針。 有關詳細信息，請訪問http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#compressedOop

64位較慢的原因是大量垃圾收集暫停。 構建更多堆意味着GC在從未使用的對象清理它時需要完成更多工作。 在現實生活中它意味着在構建大於12-16GB的堆時必須格外小心。 如果沒有微調和測量，您可以輕松地引入跨越幾分鍾的完整GC暫停。

64位的一個理由是32位服務器硬件現在非常罕見。 因此，在服務器上使用32位軟件的人並不多。 32位jvms仍然存在的主要原因是支持32位客戶端軟件用於較舊的32位系統以及applet，這些小程序通過32位瀏覽器中的插件運行。

因此，如果32位版本中存在異國情調的漏洞，您可能是第一個發現的漏洞。 這些將是在桌面系統上不太明顯的錯誤類型，在長時間運行的服務器端軟件中更明顯。 幾周/幾天后想想神秘的崩潰。 內存泄漏等

所以，如果你在服務器上進行部署，除非你有非常強烈的理由不這樣做，否則幾乎要去64位。 在Java的內存使用和垃圾收集方面，有很多snakeoil解決方案。 所以，除非你能用一些可靠的指標來支持它，否則我會謹慎地將其作為一種論證。 根據我的經驗，知道如何正確調整jvm的java工程師實際上非常罕見，並且大多數似乎只是在JVM_ARGS上隨機復制粘貼內容，直到它有效。 他們中的大多數人最終都會使用不是最佳的解決方案，不再適合他們使用的JVM，或者主動有害的解決方案。 Jvm調音是一種黑色藝術。 除非你知道自己在做什么，否則最好不要亂用它。