There are a few distinct differences and subtle nuances between 32-bit JVM and 64-bit JVM. We thought we will try to clarify them through this question & answer article.

Do I need to understand the difference between 32-bit JVM and 64-bit JVM?

If you aren’t building a performance critical application, you don’t have to understand the difference. The subtle difference between 32-bit JVM and 64-bit JVM wouldn’t make much difference to your application. You can skip reading further

Does 64-bit JVM perform better than 32-bit JVM?

Most of us think 64-bit is bigger than 32-bit, thus 64-bit JVM performance will be better than 32-bit JVM performance. Unfortunately, it’s not the case. 64-bit JVM can have a small performance degradation than 32-bit JVM. Below is the excerpt from Oracle JDK documentation regarding 64-bit JVM performance:

“Generally, the benefits of being able to address larger amounts of memory come with a small performance loss in 64-bit VMs versus running the same application on a 32-bit VM.

The performance difference comparing an application running on a 64-bit platform versus a 32-bit platform on SPARC is on the order of 10-20% degradation when you move to a 64-bit VM. On AMD64 and EM64T platforms this difference ranges from 0-15% depending on the amount of pointer accessing your application performs.”

If there is a performance hit, why would anyone use 64-bit JVM?

In 32-bit JVM maximum, addressable memory space is only 2^32 (i.e.~4gb). It means your maximum memory size of your java process can’t be more than 4GB. Due to various additional constraints (such as available swap, kernel address space usage, memory fragmentation, and VM overhead), in practice, the limit is much lower. Below table summarizes maximum heap size (i.e. -Xmx) that you can set on 32-bit JVM:

OS MaxHeap
Linux 2 - 3GB
AIX 3.25 GB
Windows 1.5GB
Solaris 2 - 4GB
Mac OS X 3.8GB


Whereas if you are running your application on a 64-bit JVM, maximum addressable memory space is 2^64 (i.e. 16 Exabytes). It means your application’s maximum addressable memory size is close to infinite.

Why 64-bit JVM performance can be slower than 32-bit JVM?

This is due to the fact that every native pointer in the system takes up 8 bytes instead of 4. The loading of this extra data has an impact on memory usage which translates to slightly slower execution depending on how many pointers get loaded during the execution of your Java program. The good news is that with AMD64 and EM64T platforms running in 64-bit mode, the Java VM gets some additional registers which it can use to generate more efficient native instruction sequences. These extra registers increase performance to the point where there is often no performance loss at all when comparing 32 to 64-bit execution speed.

What are the things to consider when migrating from 32-bit JVM to 64-bit JVM?

a. GC Pause times

The primary reason to migrate from 32-bit JVM to 64-bit JVM is to attain large heap size (i.e. -Xmx). When you increase heap size, automatically your GC pause times will start to go high, because now there is more garbage in the memory to clear up. You need to do proper GC tuning before doing the migration, otherwise your application can experience several seconds to few minutes pause time. You can use the tools like GCeasy to come up with right GC settings for newly increased heap size.

b. Native Library

If your application is using Java Native Interface (JNI) to access native libraries, then you need to upgrade the native libraries as well. Because 32-bit JVM can use only 32-bit native library. Similarly, 64-bit JVM can use only 64-bit native library.

What is CompressedOops? Is it related to 32-bit, 64-bit JVM?

jvm-object-header-size.jpg

Yes, CompressedOOps is related with 32-bit, 64-bit JVM.

We define objects with data fields. When this object is created in memory, along with data fields, an object header is also created. Object Header is needed by the JVM to do housekeeping, virtual method invocation, garbage collection, locking… This object header occupies 8 bytes in 32-bit JVM and 16 bytes in 64-bit JVM. 8 bytes increase might not sound to be much, but given that your application creates millions of objects during its runtime, 8 bytes multiplied by millions of objects can add considerable overhead.

You can mitigate this problem by passing -XX:+UseCompressedOops JVM argument. When you pass this argument JVM makes a clever trick and optimizes the object header size to use only 12 bytes even in 64-bit JVM. This clever trick will work as long as your JVM heap size (i.e. -Xmx) is less than 32GB. If it goes beyond 32 GB, then object header size will once again become 16 bytes.

Note: -XX:+UseCompressedOops has been made default since Java SE 6u23 and later. Only if you are running on JDK 6u23 or earlier release, pass the -XX:+UseCompressedOops argument.

When should I use 32-bit vs 64-bit JVM?

< 2GB memory: If your application’s heap size (i.e. -Xmx) is less than 2GB, then it’s no brainer decision. Go with 32-bit JVM.

> 2GB memory: If your application needs more than 2GB, then also it’s no brainer decision. Go with 64-bit JVM. However, do proper performance tests to measure and mitigate the impact.

How to find whether my application is running on 32-bit or 64-bit JVM?

There are few options. Let me show couple of options:

Option 1: From the command prompt issue the command:

java -version

If it’s a 64-bit JVM, you will see the output to contain word: “64-Bit”. Example:

java version "1.8.0_181"
 
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
 
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)

If it’s a 32-bit JVM, you will *not* see the word: “64-Bit”. Example:

java version "1.8.0_211"
 
Java(TM) SE Runtime Environment (build 1.8.0_211-b12)
 
Java HotSpot(TM) Client VM (build 25.211-b12, mixed mode)

Option 2: You issue following statement from your java program:

System.out.println(System.getProperty("sun.arch.data.model") + "-bit JVM");

Based on the JVM type appropriate version will be printed on the console.

Can I run 32-bit JVM on a 64-bit Operating System?

There 32-bit OS and 64-bit OS. If you are running on 32-bit operating System (which is rare to find these days), you can run only 32-bit JVM. On the other hand if you are running on 64-bit operating system, you can run your application either on 32-bit JVM or on a 64-bit JVM.

How to download 32-bit JVM, 64-bit JVM?

When you go to Oracle JDK download page, you will see options to download JDK specific to your operating system:

jdk-download-32-bit-64-bit.jpg

Here if you choose x86, you will be downloading 32-bit JVM. If you choose x64, you will be downloading 64-bit JVM. Things would have been lot simpler if they could have named it as “Windows 32-bit JVM”, “Windows 64-bit JVM”.

Can the code compiled on 32-bit JVM, run on 64-bit JVM?

We use javac i.e. java compiler to compile the java code to byte code (i.e. *.class files). Generated bytecode is agnostic of 32-bit, 64-bit JVM. It can run on both JVMs. Remember the age-old promise “Write once, run anywhere”.

Reference article: https://blog.gceasy.io/2019/05/31/do...atter-anymore/