32 OR 64 BIT for the JVM?

Question

While reading this book over here.

I can see the following section, which says:

32 OR 64 BIT? If you have a 32-bit operating system, then you must use a 32-bit version of the JVM. If you have a 64-bit operating system, then you can choose to use either the 32- or 64-bit version of Java. Don’t assume that just because you have a 64-bit operating system, you must also use a 64-bit version of Java.

If the size of your heap will be less than about 3 GB, the 32-bit version of Java will be faster and have a smaller footprint. This is because the memory references within the JVM will be only 32-bits, and manipulating those memory references is less expensive than manipulating 64-bit references (even if you have a 64-bit CPU). The 32-bit references also use less memory.

Chapter 8 discusses compressed oops, which is a way that the JVM can use 32-bit addresses even within the 64-bit JVM. However, even with that optimization, the 64-bit JVM will have a larger footprint because the native code it uses will still have 64-bit addresses.

The downside to the 32-bit JVM is that the total process size must be less than 4GB (3GB on some versions of Windows, and 3.5GB on some old versions of Linux). That includes the heap, permgen, and the native code and native memory the JVM uses. Programs that make extensive use of long or double variables will be slower on a 32-bit JVM because they cannot use the CPU’s 64-bit registers, though that is a very exceptional case.

Programs that fit within a 32-bit address space will run anywhere between 5% and 20% faster in a 32-bit JVM than a similarly-configured 64-bit JVM. The stock batching program discussed earlier in this chapter, for example, is 20% faster when run on a 32-bit JVM on my desktop.

The lines says 32-bit will be faster for lesser heap size (less than 3GB). If this is true, I want to know the reason behind it, what makes 32-bit JVM is faster?

Answer 1

I'm skeptical of the author's claim that using the 32-bit version of the JVM will give a 5% to 20% performance improvement. However, I don't use Java much so I don't know for sure. But in order to investigate this claims I looked at the some of the results from SPEC.

I searched for the SPECjEnterprise2010 results and the highest score for an x86-64 architecture was an Oracle system that used a 64-bit version of the JVM.

I also looked at SPECjvm2008 in case these smaller workloads might benefit from the 32-bit architecture. But again the best performing x86-64 system, this time from Huawei, was using the 64-bit version of the JVM.

If the 32-bit version of the JVM really was better I would expect that people submitting their SPEC results would have selected that when tuning their workloads (but I could be wrong).

I don't doubt that there are some workloads where the 32-bit version of the JVM will outperform the 64-bit version. As others have noted it uses more memory for addresses. However, the x86-64 architecture has more registers available and I suspect that the 64-bit mode of operation is where most of the optimization work is focused.

System performance has many components, and I don't think that the 32-bit version of the JVM will necessarily outperform the 64-bit version (for one this this will only matter for CPU bound workloads). I'd say that if you got to this point in the performance tuning process that you would want to check your own workload for the two different options, and use the outcome of your own tests for making a decision rather than assuming that using the 32-bit is better than 64-bit because of saving memory space for addresses as a rule of thumb, because there are other factors that could be more important than this.