Understanding 32-bit architecture in detail
As 64 > 32 then this would be an easy answer: if possible, always choose 64-bit? Wait, hold your horses. The downside of the 64-bit architecture is that the same data structures consume more memory. Our measurements show that depending on the JVM version and the operating system version along with hardware architecture you end up using 30-50% more heap than on 32-bit. Larger heap can also introduce longer GC pauses affecting application latency – running a full GC on a 4.5GB heap is definitely going to take longer than on a 3GB one. So it will not be correct to jump on the 64-bit bandwagon just because 64 is bigger than 32.
When should you ever desire to use a 64-bit JVM at all then? In most cases, the reason is large heap sizes. On different architectures, you quickly face limitations of maximum heap size on 32-bit architectures.
OS
|
Max
|
heapnotes
|
Linux
|
2GB
|
3GB on specific kernels, such as hugemem
|
Windows
|
1.5GB
|
Up to 3GB with “/3GB” boot flag and JRE compiled with /LARGEADDRESSAWARE switch)
|
Mac OS X
|
3.8GB
|
Reason – Address space for 32-bit system
As you may be aware of that in any 32-bit operating system, you can theoretically allocate up to 4GB of RAM. It is simply because the size of a 32-bit value will not allow any more references in memory.
2^32 = 4,294,967,296 i.e. roughly 4.29 GB
What breaks this on Windows is how process address space is handled. Windows cuts the process address space in half. One-half of it is reserved for the kernel (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 most often left with just 1.5-1.8GB of the heap on machines(Windows boxes).
What’s maximum amount of RAM that will be allocated to java on a 32-bit machine vs. 64-bit machine?
On the 64-bit system, theoretically, the 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 a 32-bit machine, the limit is 4 GB, and about only 1.5 GB is actually available for user applications for reasons stated earlier.
Trick to increase the heap space on 32-bit machine
We 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 heap size.
How 64-bit architecture is different?
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 up to 8 TB of virtual memory without any special configuration (besides it must be present in your system). It is a huge factor for choosing your next machine when you consider applications like video editing or virtual machines that may need to use enormous amounts of RAM.
Which versions of java you should install on 32-bit/64-bit machines?
Strictly speaking, on a 32-bit CPU architecture machine, we should install 32-bit java/JRE. On the other hand, on a 64-bit CPU architecture machine, we are free to choose between 32-bit java/JRE and 64-bit java/JRE. Both will work just fine.
In fact, on 64-bit machine decision of JRE version depends on other factors such as maximum memory needed to run our application in high load scenarios.
We should aware that high availability of memory doesn’t come for free. It does have a cost on runtime.
1) 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.
2) Longer garbage collection pauses
Building up more heap means there is more work to be done by GC while cleaning it up from unused objects. What it means in real life is that we have to be extra cautious when building heaps larger than 12-16GB. Without fine tuning and measuring, we can easily introduce full GC pauses spanning several minutes which can result in showstoppers.
Can a class (=.class) file generated using a 32-bit java compiler be used on 64-bit java?
Yes, Java bytecode is independent of 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 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.
References:
No comments:
Post a Comment