Nov 12 2008
64-bit Architecture and Apparent Issues with Java Applications
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.