如果你要買一輛車而且你的首要目標是性能或者更具體的說是原始動力，那麼在4缸發 動機和8缸發動機之間選擇的話，答案很顯然，因為越大越好。通常而言，當我們看計算 機配置列表或者產品宣傳的時候，64位的性能也比32位有優勢，同樣四核比雙核更棒。
然而許多在大同世界裡很簡單的道理包括越多/大越好，移到計算機領域裡就不是那麼 回事了。當處理多重CPU時，你會覺得那些多核所多出來的處理單元很有用，但如果你的 工作僅僅是單線程的，那你要做的卻是讓其他核一邊歇著。
32位與64位的比較則更加細微。x86-64 架構不僅在x86架構的基礎上增大了寄存器， 而且還增加了寄存器的數量。從基本上說這會帶來更好的性能（因為更多的寄存器可以讓 編譯器創建更好的機器代碼）。然而很不幸，至今把Java從32位移到64位帶來的只是性能 的下降。
談到Java的性能，runtime的兩個方面很關鍵：JIT和GC。JIT的作用使盡可能快地執行 代碼；GC的作用是（在管理存儲的同時）從代碼的執行中抽取盡可能少的時間。因而Java 的性能是讓JIT（在更多存儲器的幫助下）產生更多理想代碼，並減少GC用以管理存儲的 時間（指針越大這越困難）
Java 9最初是設計為32位系統的而且這影響了我們在代碼基（code base）做的一些早 期決定。早幾年前我曾花費不少時間試圖在運行64位的PowerPC系統上運行我們的 Smalltalk VM，得到的結論是：最直接的解決方式是讓所有的數據結構（對象）變得兩倍 大來處理64位指針。隨著Java 9的發展（大約2001），我們拿到手的最早的一個64位系統 是一個Dec Alpha，所以我們采用了這種最直接的“變大”解決方法，允許一 個通常的代碼基既支持32位也支持64位。
64位CPU擁有更寬的數據總線，但是同樣是這個64位CPU可以運行32位的代碼，而且擁 有同樣寬的數據總線。回頭看看我們64位的解決方案——將數據結構變得兩倍 大，效果卻不如相同硬件上的32位，也就是說64位不及32位。這個問題不是Java 9也不是 Java所獨有的，因為所有的64位都需要數據擴展。只是說Java語言將這一問題凸顯得更加 明顯，因為Java編程通常與創建、操控對象（也稱數據結構）有關。
性能問題的解決方法是聰明地處理數據結構，這也正是我們在Java6 JDK中使用壓縮列 表特性（compressed references feature）所做的。我們可以玩小聰明而且不會被抓到 ，因為使用者（Java程序員）並不清楚Java對象更深處的表現。
折中的處理方法是通過在對象內存儲更少的信息，限制可以被JVM使用的存儲。這是一 個相當不錯的處理方法，因為計算機存儲的規模遠不及64位的極限地址范圍。我們僅使用 32位來存儲指針，並充分利用8字節對象對齊（aligned objects）來得到一些空位（指針 << 3）。因此使用壓縮列表（compressed references） ——Xcompressedrefs，IBM Java6 JDK可尋址高達32Gb的堆。
並不只我們使用這種技巧，Oracle/BEA有-XXcompressedRefs，Sun有- XX:+UseCompressedOops。當然，不同廠商的方法在限制和支持等級上略有不同。也許你 會有異議，但當用戶運行到32位操作系統的堆棧極限時，他們就想要64位系統（同時還要 不損失性能）。
