Does increasing the number of available cores and RAM cause the JVM to perform more GCs?

Question

I'm upgrading production hardware, and we're seeing far more young-gen GCing on the new set of kit compared to the old.

The same program is running (identical binaries) on both machines. One obvious difference (I hope this doesn't make a difference to the JVM) is that we have upgraded RHEL5 -> RHEL6.

Our JVM (Java 64-bit Hotspot 1.6, same java -version on both) is running with the same command-line GC options:

-XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseParallelGC -XX:+UseCompressedOops

Also:

-Xmx1024M -Xms1024M -XX:NewSize=512M -XX:SurvivorRatio=2

The difference between the machines is that the new box has approximately twice as much RAM (32gb - although the max heap is unchanged) and some more cores (24 vs. 16).

The application itself connects to several external processes and performs lots of network operations - so this could indicate some regression, misconfiguration, or incompatibility (this is why we test...). What I would like to know is:

Is an increased level of young-gen GC likely to be a natural and expected consequence of running on more cores, or should I be concerned about this development?

We confirmed the number of GCs in JConsole, but that's about the same as doing:

grep "PSYoungGen" ./log | wc -l 

(note -XX:+PrintGC -XX:+PrintGCDetails)

Full GCs look about the same on both boxes.

Note, this is the number of GCs over the course of the whole application startup process - so it's not performing "more work." It's the same work, with more GC runs.

I wondered, for example, whether -XX:+UseParallelGC would lead to lots more entries in the log, because more threads were being used (chopping the young-gen collections into smaller pieces, meaning more, smaller collections - not something to be worried about).

Answer 1

Puzzling question...

Short answer

No, the GC frequency is only a function of your creation rate. Unless your application takes advantage of this new hardware, the GC frequency should be identical.

Long answer

I don't think it is related to the OS upgrade, nor do I think the increase in total RAM has something to do with it.

It cannot come from an increase in pointers size since the maximum heap size is 1GB. So the JVM already uses 32-bits pointers, even if you are on a 64-bits JVM.

Is your application using all of the cores during startup ?

It could explain the increase in YoungGC rates : If you application uses 8 more threads, it means that it will perform more work for the same amount of time. You should observe an increase in the allocation rate (see your GC logs).

You should also notice a drop in Young GC duration, since PSScavenge uses more threads. Is this correct ?

According to this page, ParallelGCThreads = (ncpus <= 8) ? ncpus : 3 + ((ncpus * 5) / 8). You were using 13 threads for a YGC cycle and now are using 18.