JRE 32bit vs 64bit

Question

I have been using Java for a while, and my typical ritual of creating a new machine for developers requires the normal download and installation of the latest JDK from the Oracle site.

This caused an unusual question today, does it matter if I use the 32bit or 64bit JRE bundle?

After thinking about it, I installed both versions before this, and my regular plugchain plugs into Eclipse. In my day-to-day programming, I don’t remember ever changing something or thinking about something different, simply because I used a 64-bit JRE (or aimed at a 64-bit JRE for this).

From my understanding of 64-bit and 32-bit - it really comes down to how numbers are stored under covers ... and I know that int is 32 bits and long is 64 bits ... the same thing when float is 32 bits, and double is 64 bits - is it that simple that Java distracted even this subtlety and was possibly “64 bit compatible”?

I am sure that I missed something, except that I could not install the 64-bit JRE on a 32-bit system.

Answer 1

64-bit and 32-bit actually come down to the size of references to objects, and not to the number of numbers.

In 32-bit mode, references are four bytes, which allows the JVM to uniquely address 2 ^ 32 bytes of memory. This is the reason that 32-bit JVMs are limited to a maximum heap size of 4 GB (in fact, the limitation is less due to other costs of the JVM and OS and varies by OS).

In 64-bit mode, links have (surprisingly) eight bytes, which allows the JVM to uniquely address 2 ^ 64 bytes of memory, which should be enough for anyone. JVM heap sizes (specified with -Xmx ) in 64-bit mode can be huge.

But 64-bit mode is expensive: there are twice as many links, which increases memory consumption. That's why Oracle introduced Compressed Oops . When oops compression is enabled (which, I believe, is now used by default), object references are reduced to four bytes with the caveat that the heap is limited to four billion objects (and 32 GB Xmx). Compressed operations are not free: to achieve such a significant reduction in memory consumption, small computational costs are required.

As a personal preference, I always run the 64-bit JVM at home. The processor supports x64, the OS also, so I like that the JVM also works in 64-bit mode.

Answer 2

As you noticed, primitive numeric types in Java are clearly defined.

However, the choice between 32-bit and 64-bit JVMs can make a difference if your Java application uses native code libraries that can be created for use in a 32-bit application, in a 64-bit application, or both.

If you have native libraries that support only 32-bit applications, you need to either use the 32-bit JVM or create 64-bit versions of the libraries.

Answer 3

Depending on the context, for local development I will always use the 64-bit JDK. First of all, because I most likely will need all the memory space for collectors and IDEs.

As for integration into production, I would recommend 32-bit if possible. Why?

For some Java EE servers that are licensed for use in production, this will depend on some factors, such as the machine, how many cores, etc. For WebSphere Liberty Profile, you are also limited to 2 GB.

64-bit JREs will take up a bit more memory, and if you are trying to limit it to something like 2 GB or better, but a 2x 1 GB cluster, you will have more flexibility to do without paying a percentage.

From https://plumbr.eu/blog/java/should-i-use-32-or-64-bit-jvm

Problem 1: on a 64-bit basis, 30-50% of the additional heap is required. Why is that? Mainly due to the memory layout in 64-bit architecture. First of all, the object header is 12 bytes on a 64-bit JVM. Secondly, object references can be 4 bytes or 8 bytes, depending on the JVM flags and heap size. This definitely adds some overhead compared to 8 bytes on headers for 32-bit and 4 bytes for links. You can also dig into one of our earlier posts for more information on calculating object memory consumption.

Problem 2: Longer garbage collection is paused. Creating more heaps means that the GC will work harder, clearing it of unused objects. In real life, this means that you have to be especially careful when creating heaps larger than 12-16 GB. Without fine tuning and measuring, you can easily enter full GC pauses spanning several minutes. In applications where latency is not critical, and you can optimize for bandwidth, this can only be OK, but in most cases it can become showstopper.

To limit the impact of your Java EE environment, upload parts of it to other microservices, such as ElasticSearch for search, Hazelcast for caching, your database for storing data, and save your Java EE server to host the application core itself, and not to run services inside it .

Answer 4

I think there are two main differences. One of them is mentioned here, but not the other.

On the one hand, as mentioned above, memory and data types . 32-bit and 64-bit JVMs use different native data types and memory spaces.

• 64-bit JVMs can allocate (can use) more memory than 32-bit ones.
• 64-bit ones use their own data types with higher bandwidth, but take up more space. Because the same object can take up more space.
• For JVMs that the Garbage Collector (GC) freezes the machine, versions with 64 bits may be slower because the GC has to check large heaps / objects and it takes longer.
• There is an IBM presentation explaining these differences.

And on the other hand, supported native libraries . Java programs that use the JNI to access native libraries require different versions depending on the type of JVM.

• 32-bit JVMs use 32-bit native libraries and 64-bit JVMs use 64-bit libraries.
• This means that if your program uses libraries that rely on native code, such as SWT, you will need different versions. Pay attention to the SWT download page , there are different versions for Linux / Windows 32-bit and 64-bit. Note that there are different versions of Eclipse (each with a different version of SWT) for 32-bit and 64-bit.
• Some applications, such as Alloy, are packed with 32-bit native libraries. They do not work with 64-bit JVMs. You can solve these problems by simply downloading the appropriate 64-bit native libraries and configuring JNI accordingly.

Answer 5

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

If you are not creating a performance-critical application, you do not need to understand the difference. The subtle difference between a 32-bit JVM and a 64-bit JVM will not make much difference for your application. You can skip reading further

Does a 64-bit JVM work better than a 32-bit JVM?

Most of us believe that the 64-bit version is larger than the 32-bit one, so the performance of the 64-bit JVM will be better than the 32-bit performance of the JVM. Unfortunately, this is not the case. A 64-bit JVM may have a slight performance degradation than a 32-bit JVM. The following is an excerpt from the Oracle JDK documentation regarding the performance of a 64-bit JVM:

"Typically, the benefits of handling large amounts of memory are accompanied by a slight performance loss in 64-bit virtual machines compared to running the same application on a 32-bit virtual machine.

The difference in performance when comparing an application running on a 64-bit platform with a 32-bit platform in SPARC is about 10-20% when switching to a 64-bit virtual machine. On AMD64 and EM64T platforms, this difference ranges from 0 to 15% depending on the number of pointers accessing your application. "

Whether the 32-bit JVM or the 64-bit JVM matters.

What to consider when upgrading from a 32-bit JVM to a 64-bit JVM? a. GC Pause Time

The main reason for migrating from a 32-bit JVM to a 64-bit JVM is to achieve a large heap size (i.e. -Xmx). When you increase the heap size, the GC delay time automatically starts to increase, because now there is more garbage left in the memory for cleaning. Before migrating, you must correctly configure the GC, otherwise your application may take from a few seconds to several minutes. You can use tools like GCeasy to find the right GC settings for the newly enlarged heap size.

b. Native library

If your application uses its own Java interface (JNI) to access its own libraries, then you also need to update your own libraries. Because the 32-bit JVM can only use the 32-bit native library. Likewise, a 64-bit JVM can only use a 64-bit native library.