假如你要买一辆车并且你的首要方针是功能或许更详细的说是原始动力，那么在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位体系（一起还要不丢失功能）。
