I did a little research yesterday morning on the question of the impact of using 32 v. 64 bit Java. Here's what I found.
The short answer is that for building, it doesn't really matter at all. You can think of the 64 bit JVM as just another platform for your java classes to run on. So just as you can build your Java app on your Windows laptop and deploy it to a machine running Linux, you can build on a 32 bit system using 32 bit java and deploy to a 64 bit system running 64 bit java, or vice versa. The Java bytecode is still independent of the processor architecture.
The main advantage of a 64 bit virtual machine is the ability to access much larger heap sizes. Also, the virtual machine can manage many more threads (probably good for a web server that is handling thousands or millions of requests simultaneously). While the theoretical limit for heap size on a 32 bit system is 4GB, in practice the maximum varies from 1.5G to about 3G. I believe a 32 bit JVM running on 64 bit system might be able to get closer to that 4GB limit (have to check on that). A 64 bit JVM should be virtually unlimited (as long as there is enough physical memory on the system).
Now, because a 64 bit JVM uses pointers that are double the size of the 32 bit JVM (64 v 32), it uses more memory on average. It is also somewhat slower. For these reasons, and until my project has a need to use a much larger heap size, I've recommended distributing the latest 32 bit JRE with our software and keeping our CI environment at 32 bits. For developer environments, we can use whatever suits us.
References:
1. Frequently Asked Questions About the Java HotSpot VM (64-bit Java).
ion
2. 64-bit versus 32-bit Virtual Machines for Java.
3. Java Tuning White Paper:
No comments:
Post a Comment