As our clients are moving to 64-bit architecture for their servers and ColdFusion installations I am paying particular attention to performance charactaristics when running ColdFusion 64-bit on the Sun 64-bit 1.6 JVM.  There is no doubt that we witness an immediate increase in the available heap size, we can now allocate much higher amounts of memory to the Sun JVM heap by using the -Xms and -Xmx arguments, in the jvm.config file.  

Most of our clients are still on 32-bit systems but on those that have deployed on 64-bit I can certainly see more available heap memory available than on 32-bit, if of course they set that to a higher number with the -Xms and -Xmx arguments.  I always enable "metrics logging" so I can observe those things.  Here is how to enable metrics logging.  Beyond the observation of more heap memory there does seem to be a sort of ceiling where we do not see much in the way of overall performance gains.  As yet I have not been able to quantify that; however a discussion I recently took part in made me think about using alternative JVM's to the Sun JVM.  Here is why.  IBM seem to be doing a lot of work with their Java 6 SDK in order to take full advantage of the subtle differences in 32-bit to 64-bit architectures.  As I mentioned above, I was in conversation with an IBM engineer and he explained it to me as follows. Java was created without 64-bit in mind and it appears that languages with lots of data-structure manipulation can suffer a little on 64-bit architectures because 64-bit CPU's have a wide data bus.  Java is a such a language as it involves creating and managing objects which are in essence "data-structures".  Because of the wide date bus nature of a 64-bit architecture each object is likely to be larger.

On the IBM BM Java6 JDK virtual machine, IBM have introduced a way of dealing with this potential issue. They are using an argument called "-Xcompressedrefs" the effect of this is to store less data in the object and there is a trade-off in that sense.  However this still allows the heap to use up to 32GB which is still much larger than the current level of around 1.4GB on Windows 32-bit.

So the conclusion of this IBM engineer is that without this -Xcompressedrefs argument Java applications which create a lot of referenced objects can and in his experience often do run slower on 64-bit systems.  This gives me great food for thought in particular with applications using the current "triumverate" of frameworks; mach-ii/ModelGlue-ColdSpring-Reactor/Transfer which by nature probably create more referenced objects than other paradigms.  By coincidence, we were testing a client application over last weekend.  That client wanted to know the performance difference between running the same application on 32-bit Windows 2003 and 64-bit Windows 2003. This applications uses ModelGlue-ColdSpring-Reactor and the same tests on 64-bit ran slower than the 32-bit tests.  We are still evaluating exactly why but the information I am blogging about here gives me, as I say, great food for thought.

By the way, the Sun JVM which ColdFusion ships with, is also hitting this issue, it is an overall Java issue.  There is what is called a "performance" Sun JVM which is in some sort of alpha-beta phase; so time permitting, we will be doing some tests on the different JVM's.