64 bit Java on slamd64 (64 bit slackware)
April 5th, 2009
slamd64 - 64bit Slackware
slamd64 is Fred Emmott’s 64bit Slackware project. I installed it on a couple of servers that provide the bulk of the processing power behind spider.my recently. Just like installing Slackware, installing slamd64 on a server is a matter of downloading the first CD ISO in the set, and following the instructions.
The only real difference I noticed is the startup splash screen. I’m only ever going to see that once, as I never connect monitors to my servers unless they’re broken. I thought the splash screen was a nice touch. I use Slackware because I have conservative tastes in server software, but I think I’d have been disappointed if I’d had to use uname to tell I was using the new distro!
For those who won’t believe a thing until they see the screenshots, I’m not going to disappoint you -here’s the output from uname in an xterm on one of the servers running slamd64. See the ‘x86_64’? That’s what you get for buying extra RAM and installing a 64bit operating system. The SC440 I have still running Slackware reports ‘i686’ for the machine hardware name.
slamd64 uname output
Just in case you think a picture of an xterm doesn’t count as a screenshot, here’s that startup splash screen – nice huh?
slamd64 boot screen
More screenshots later, keep salivating! The servers I installed slamd64 on are Dell PowerEdge SC440 (yes, they really do work with 8GB of RAM!). They’re not the most powerful servers ever, but they are cheap, quiet and use very little power. I’ve just increased the RAM on two of them to 8GB and 6GB (rather than throw away the old memory), so I had to change my linux kernel to use the RAM beyond the 4GB / 32bit limit. I didn’t consider building a PAE kernel for long – it just seems too ‘clunky’.
It all seemed too easy. I couldn’t wait to get my Java applications started to take advantage of the extra memory. It’s not so much that I want to go ‘bloated’, more that I’m running out of spare capacity to start new instances of my application while I’m developing. I was pleased to see that a slamd64 first-CD only install includes the 64bit JRE, so I could just copy my application onto the upgraded servers and start it.
I actually installed slamd64 before fitting the extra memory, so I was a bit upset to see my Java application being killed by the OOM (Out Of Memory) killer, but pleased to see it reported briefly at 1.9g by ‘top’on a 2GB system! Before I installed slamd64, the most I ever saw top report was 1.7g for a java process, before the inevitable OutOfMemoryError.
After I installed the 8GB, I ran the application again with the 64bit JVM and got a shock! You can see from the top output that my application is using nearly 3 times the memory (3.7g in the picture) it does when run with the 32bit (1.7g, running concurrently in the top output) JVM! My application is a mixture of unchanging Hashtables and arrays, so perhaps I’ve managed to produce a worst-case 64bit example. I didn’t intend to!
slamd64 java processes in top (first row is 32bit JVM, below is 64bit JVM, same application)
The good news is, I can run the 32bit application under slamd64 and enjoy a larger heap. I can start the 32 bit JVM with maximum heap size up to ‘java -Xmx3700M’. A simple array-of-big-strings test program runs to 3.6GB reported by top before it runs out of heap.
I’ve obviously got some work to do before I fully expoit the potential of the 64 bit JVM. The good news is I can keep running the 32 bit JVM under slamd64, and get access to an extra 2GB of RAM that way. The bad news is, it appears as though the 32-bit JVM can only run in the bottom 4GB of RAM (but you knew that, didn’t you?). To use all 8GB with a 32-bit JVM would require either PAE, or running the JVMs inside Virtual Machines such as VirtualBox.
