I’ve been toying around with Spotifun – a Grails based webapp – on a Rackspace cloud virtual machine.
The entry level rackspace offering is an instance with just 256 MB memory. I quickly discovered that 256 of RAM doesn’t cut it for running Tomcat with a single Grails app with a few grails plugins (~50MB WAR file size). The WAR barely deployed before the JVM ran OutOfMemory.
Decided to migrate my instance to a Rackspace plan with 512 MB of RAM. This offered a sort-of reasonable experience. But just sort-of, frequently episodes which excessive 10+ second response times would occur. Heavy garbage collection and/or swapping activity appeared to be a likely culprit, but as I was to cheap to just upgrade to a plan with even more memory I decided to whip out JConsole and have a look on the running JVM via JMX. I discovered that the JVM on the Rackspace instance was far more memory hungry than the JVM on my development work station. Almost twice the amount of heap memory was used (measured post Tomcat startup)! And this on a system constrained to 512 MB (of which mysql and the base Ubuntu OS will obviously claim a significant share). Further investigation led me to the reason:
# uname -a Linux 2.6.24-23-xen #1 SMP Mon Jan 26 03:09:12 UTC 2009 x86_64 GNU/Linux
Rackspace is obviously running on x64 hardware, causing Ubuntu apt-get to install a 64-bit JVM when java is installed. 64-bit software generally occupy more memory than their 32-bit counterparts, see the Wikipedia article on the subject for further details. The remedy is in this case however only a:
apt-get install ia32-sun-java6-bin
…away. A quick change to JAVA_HOME in Tomcat’s startup script to ensure that the correct JVM is used and memory consumption was back to sane levels. After reverting to a 32 bit JVM I’ve yet to see abnormal response times from Spotifun.
Slackhacker 
If you’re using jdk6u14 or newer, try running with compressed oopts:
-XX:+UseCompressedOopts
this will make it behave almost like a 32bit jdk if you dont need to map 4gb+
Thanks for the tip!
I’ve been googling around but cannot find any documentation for the JVM option though…?
Just out of curiosity, what has a 64bit JVM going for it other than the capability to map huge amount of memory?
| Just out of curiosity, what has a 64bit JVM going for it
| other than the capability to map huge amount of memory?
nothing i guess. In theory a 64 bit jvm should run faster on a 64 bit plattform (running nativly and all), but this does not seem to be the case (on sparc solaris).
And when would you want to address more than 32 bits memory in your JVM? JVMs larger then 4 Gigs sounds like trouble to me (gc etc etc 🙂
// Nils Harald
Actually, there is potentially a substantial advantage on x86-64 architecture platforms…
A fair number of folks seem to be unaware that along with being able to address > 4G (or 2G on Windows), you get the added benefit of the extra set of registers, as well as the widened 64-bit wide registers. As long as the JVM itself is optimized to take advantage of the widened and deepened register file, the JVM, at least, will run a bit faster in 64-bit mode.
What I’m not 100% sure about is if your JIT’d code gets to take advantage of the same boost – i.e., is the JIT aware of how to optimize for x86-64’s more advanced hardware?
From experiments I’ve run, I’ve seen that code can run marginally (and in some cases even noticeably) faster under a 64-bit JVM, so I’m inclined to believe there *is* an advantage. YMMV, though….
I had the option wrong. Its actually
-XX:+UseCompressedOops
as you can see in the jdk6u14 release notes: http://java.sun.com/javase/6/webnotes/6u14.html
this feature has been around in the performance jvm for quite a while.
Thanks for the update! I have found a quite interesting blog post which highlights the benefits of UseCompressedOops. http://blog.juma.me.uk/2008/10/14/32-bit-or-64-bit-jvm-how-about-a-hybrid/
Pingback: Rackspace Cloud has some things going for it « Slackhacker