Performance difference between 64 and 32 bit Java?

[Gerco]

Hey people,

a few days ago, I encountered a strange performance issue in a Java program running on a Windows 2003 server. I managed to isolate the issue to the "get" method of HashMap.


public void run() {
HashMap map = new HashMap();
// Put a few values in the map

for(int i=0; i<10000000; i++) {
Object value = map.get("key");
}
}


This is running on a 16-cpu, 64 bit Windows 2003 Server in a 64 bit Java 5 JVM and gets 10 of the CPUs up to 100% usage when running 10 threads. When I run the exact same code (the same .class files in fact) in a 32 bit Java 5 JVM on the same machine, none of the CPUs show any noticable activity and running the sample takes dozens of times more time.

Does anyone know why this is? Running on just 2 CPUs doesn't seem to produce the same issue and I don't have access to anything with more than 4 CPUs to perform further analysis.

[kjkoster]

Dear Gerco,

I am curious what precise JVM you were using in each case? Do you run the JVM with the -server flag or not?

See also the discussion here: http://java-monitor.com/forum/showthread.php?t=18

You can hook up JConsole to the JVM (http://java-monitor.com/forum/showthread.php?t=1) to find out what HotSpot compiler is being used, Client, server or that other one whose name I forgot.

Kees Jan

PS. A 16-cpu box? Some guys have al the luck.

[Gerco]

I was running Sun Java SE 1.5.0_11 in both 32 and 64 bit if I'm not mistaken, not using the -server flag in my tests though. I wonder why I was able to stress 10 CPUs to the max without that.

Anyway, when running the 32 bit JVM none of the CPUs were doing anything. If the program was limited to one CPU by not using -server, I would expect at least one CPU running at 100% usage.

Once I get access to the box again (next wednesday) I'll grab the code of the test program so I can run some tests on other systems as well. The box does have work to do though so I'm not sure if I'll be able to run tests on that. The program is now running on a 64 bit JVM so as far as my customer is concerned the problem is solved.

[kjkoster]

Dear Gerco,

Well, I'm just guessing now, but perhaps the default VM has changed between the 32 and 64 bit versions? Makes sense to default to server on 64 bit machines.

Jconsole will tell you for sure, though.

No activity at all is strange, although the program may be bouncing between cpu's, causing none to register large peaks. Just a wild guess. You can test this by setting processor affinity for the process so that it stays on a particular cpu.

Kees Jan

[kjkoster]

Dear Gerco,

Did you ever try to troubleshoot the processor usage issue? I'm really curious.

Kees Jan

[Gerco]

I has some time with the machine yesterday and I checked what was going on. You were 100&#37; right. The 32 bit VM by default runs in client mode and the 64 bit one runs in server mode. Which was the entire problem. I feel pretty dumb now :)

[kjkoster]

Dear Gerco,

Don't feel dumb, I've seen lots of situations where people were running effectively single threaded on multi-processor machines.

This is one of the reasons why Lemongrass keeps track of the Hotspot compiler version that the monitored JVM's are using. Glad the mystery was solved.

Kees Jan