如果你要买一辆车而且你的首要目标是性能或者更具体的说是原始动力，那么在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位系统（同时还要不损失性能）。
