JAVA在64位系统环境下的性能
32位与64位的比较则更加细微。x86-64 架构不仅在x86架构的基础上增大了寄存器，而且还增加了寄存器的数量。从基本上说这会带来更好的性能（因为更多的寄存器可以让编译器创建更好的机器代码）。然而很不幸，至今把Java从32位移到64位带来的只是性能的下降。
谈到Java的性能，runtime的两个方面很关键：JIT和GC.JIT的作用使尽可能快地执行代码；GC的作用是（在管理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位系统（同时还要不损失性能）。
