Things that affect SPECjbb2005 performance include compressed references, lock optimizations, lazy unlocking, software prefetching, memory locality optimizations in the GC, generic compiler enhancements and optimizations to a few core Java APIs like HashMap and BigDecimal. Most of these have been done by the JRockit team, some are inherited from Sun (the Java API changes). The team noted that lmost all of the optimizations that affect SPECjbb2005 have very broad applicability.
The 64-bit JRockit is faster than Sun because when you run the 64-bit JRockit with a small heap, it compresses the references to 32-bit which decreases the pressure on the memory bus. This yields a 10-20% performance advantage, but does not apply if you run with a larger heap. The current implementation is limited to 4 GB, though this can in theory be extended to a 32 GB heap with a slight loss in performance. This technique can obviously not be used if you need a larger heap than the limit. However, it is quite common to use a 64-bit JVM even with a small heap; for instance if you want to be able to expand the heap later or if you are integrating with any 64-bit native libraries such as a floating point library.
On a query of which JVM is the fastest, the team's answer is that "it depends". For SPECjbb2005 (and XMLMark) on x86 right now JRockit seems to be in the lead, so Henrik Stahl would expect it to be used for the upcoming Intel and AMD product launches. If you're running a BEA product you should be using JRockit since that is where the BEA team is focussing their efforts. But at the end of the day, you have to do your own benchmarking if you really want to know, concluded Stahl.