In computer architecture, 64-bit computing is the use of processors that have datapath widths, integer size, and memory addresses widths of 64 bits (eight octets/bytes). Also, 64-bit CPU and ALU architectures are those that are based on registers, address buses, or data buses of that size. From the software perspective, 64-bit computing means the use of code with 64-bit virtual memory addresses. Similarly, 32-bit computing, CPU or 32-bit programming uses 32 bits (four octets/bytes) for all the above purposes.
If you go to java download page, it lists various installation packages mentioning 32-bit packages or 64-bit packages for various platforms such as Linux or windows. Many times we worry that what package we are eligible to download and install in our systems so that our java code runs fine. In this post, I will try to put some light on these different terms and also I will try to answer some obvious questions.
You already read the basic difference between 64-bit and 32-bit computing/architectures. Now let’s expand our understanding and go deeper into bits and bytes.
1. Understanding 32-bit Architecture in Detail
As you may be aware of that in any 32-bit operating system, you are limited to 4096 MB (4 GB) of RAM. It is simply because the size of a 32-bit value will not allow any more references in memory.
232 = 4,294,967,296 i.e. roughly 4.29 GB
So, in a 32-bit system you can theoretically allocate up to 4GB of memory per process. What breaks this on Windows is how to process address space is handled. Windows cuts the process address space in half. One-half of it is reserved for the operating system (which a user process cannot use) and the other half for the user. It doesn’t matter how much RAM is in the box, a 32-bit process can only use 2GB of RAM. What’s even worse – this address space needs to be contiguous, so in practice, you are often left with just 1.5-1.8GB of the heap on Windows machines.
Tech-savvy readers might know that modern chips support PAE, a processor technology that allows the operating system to use a little bit more memory—up to 64 GB, but it also requires special application support that most applications don’t have or necessarily need.
The 4 GB limit for Windows, at least, is also a factor of licensing. The home versions of 32-bit Windows, while technically being able to support PAE, have a hard limit of 4 GB for licensing and driver compatibility reasons. I am pointing out “driver compatibility reasons” because some specific applications which highly use native files (e.g. anti-viruses) are built specifically for 32-bit/64-bit machines and native files are not compatible with other machines.
The other thing to remember is that your BIOS and other device chips in the motherboard such as video cards, also occupy some memory in same 4 GB space so the actual memory available for use by your applications reduces further to around 1.5 GB only.
While 32 bits of information can only access 4 GB of RAM, a 64-bit machine can access 17.2 BILLION GB of system memory, at least theoretically. So it must remove all the barriers of memory consumption from your system, right? But it does not.
Windows 64-bit Home editions are still limited to 16 GB of RAM [ all because of licensing reasons], but the Professional and Ultimate versions can use up to 192 GB of RAM at present due to various compatibility issues.
The per-process limit for RAM is also greatly increased—on 64-bit Windows, instead of a 2 GB limit, each application can access upto 8 TB of virtual memory without any special configuration (besides it must be present in your system). It is a huge factor in choosing your next machine when you consider applications like video editing or virtual machines that may need to use enormous amounts of RAM.
So now we have a good understanding of 32-bit machines vs. 64-bit machines. Let’s focus on stuff which is related mostly to java.
Strictly speaking, on a 32-bit CPU architecture machine, you should install 32-bit java/JRE. On the other hand, on a 64-bit CPU architecture machine, you are free to choose between 32-bit java/JRE and 64-bit java/JRE. Both will work just fine. In fact, on a 64-bit machine decision of JRE version depends on other factors such as the maximum memory needed to run your application on high-load scenarios.
3.1. High Availability
Please note that the high availability of memory doesn’t come for free. It does have a cost on runtime e.g. 30-50% of more heap is required on 64-bit in comparison to 32-bit. Why? Mainly because of the memory layout in 64-bit architecture.
First of all – object headers are 12 bytes on 64-bit JVM. Secondly, object references can be either 4 bytes or 8 bytes, depending on JVM flags and the size of the heap. This definitely adds some overhead compared to the 8 bytes on headers on 32-bit and 4 bytes on references.
3.2. Long GC Pauses
Longer garbage collection pauses. Building up more heap means there is more work to be done by GC while cleaning up unused objects.
What it means in real life is that you have to be extra cautious when building heaps larger than 12-16GB. Without fine-tuning and measuring you can easily introduce full GC pauses spanning several minutes which can result in showstoppers.
Absolutely Yes. Java byte code is independent from 32-bit or 64-bit systems. That’s why it is said that the compiled java code shall be executable on “any” system. Remember that just the virtual machine is compiled for a special system architecture because of some native files it has in packaged bundle, and native files are never platform-independent.
If so, then how 32-bit applications run on 64-bit systems? The answer is that 64-bit systems include a compatibility layer called WoW64, which actually switches the processor back and forth between 32-bit and 64-bit modes depending on which thread needs to execute; making 32-bit software run smoothly even in the 64-bit environment.
As we learned already the limits allowed on both versions in the previous discussion in this post. On 64-bit system, the theoretical limit is very high for any configuration available today (17.2 BILLION GB memory). Still, there are limitations imposed by vendors for various purposes, which mainly include licensing and compatibility with other native applications.
Similarly, on 32-bit machine, the limit is 4 GB, and about only 1.5 GB is actually available for user applications for the reasons stated above in the post.
There is a trick you can pull on 32-bit windows to reduce the kernel space and grow the user space. You can use the /3GB parameter in your boot.ini. However, to actually use this opportunity, the JVM must be compiled/linked using the /LARGEADDRESSAWARE switch.
This unfortunately is not the case, at least with the Hotspot JVM. Until the latest JDK releases the JVM is not compiled with this option. You are luckier if you are running on a jRockit on post-2006 versions. In this case, you can enjoy up to 2.8-2.9 GB of the heap size.
That’s all for this topic. Please drop a comment if something is not clear, or you simply disagree with me.
Happy Learning !!