Java code 32 bit

How to find if JVM is 32 or 64 bit from Java program? Example

You can find JVM bit sizes like 32 bit or 64 bit by using either running java command from the command prompt or by using System.getProperty() from Java program. The question is why do you want to know hardware or platform configuration while writing Java code which is supposed to write once and read anywhere(32 bit, 64 bit, etc)? Yes we don’t really need to know whether JVM is 32 bit or 64 bit more often but there are many situations when this matters

Check if JVM is 32 or 64 bit from the Java program:

1. Since in 32 bit JVM maximum heap size in Java can not be more than 4GB (theoretically) if you can get JVM version from a script like running java command you can have a different memory configuration for your application. Also, if there are any specific JVM options which only applicable to 64 bit JVM than you can set those.

2. If your Java application is using native libraries then you certainly want to know whether Java running on the host is 32 bit or 64 bit because the native library may have different versions loaded for 32 bit or 64-bit architectures.

I am sure there could be some more practical reasons when you like to find JVM bit size or whether JVM is 64 bit or not

And, if you are serious about improving your advanced JVM skill and learn things like taking and analyzing heap dumps then you can also see these advanced courses for Java programmers to learn more about Performance and Memory managemen t including troubleshooting memory leaks in Java.

How to check if JVM is 32 or 64 bit in host

As I said earlier there are two different approaches either using Java system property like » sun.arch.data.model » or » os.arch » or by running java command from the script and checking its output for certain characters to identify whether JVM is 64 bit or not. let’s see an example of different ways to find if JVM is 32 bit or 64 bit:

1. By using System property sun.arch.data.model :

You can find whether your JVM is 32 bit or 64 bit by calling System.getProperty(«sun.arch.data.model») at least on Sun’s hotspot JVM. I don’t expect this to be run on any other Vendor-specific JVM but since most of the programmer or project uses Sun’s hotspot JVM. this is a handy option.

For 32 bit JVM » sun.arch.data.model » will be 32 and for 64 bit JVM, this would be 64. here is an example:

2. By using System.getProperty(« os.arch «)

» os.arch » is another System property that you can use to find whether installed JRE or JVM is 32 bit or 64 bit. by name, it sounds that it will return the operating system arch but you can still give it a try. Though I haven’t tested on all different JVM, I have read that it can indeed return JVM Bitness.

If you try this on a 64-bit machine and 32 bit JVM combination then please let us know what does it return. here is what it returns in the case of 32 bit JVM:

3. java -d64 -version

4. java -version

Plain old java -version reveals information about JVM bitness only if installed JRE is 64 bit, in case

of 32 bit JVM it doesn’t provide any information related to architecture but in the case of 64 bit JVM it

That’s all on how to find if JVM is 32 bit or 64 bit from Java program and command prompt. As I said it’s particularly useful if you have a dependency on native libraries which have a different build for 32 bit or 64-bit architecture. Let me know if you have some more ways to find JVM is 64 bit or not, you can also share on which scenario you need to know JVM bitness.

9 comments :

I wanted know whether my JVM is 64 bit or not and found your tips very relevant. I don’t require check if JVM is 32 bit but if any JVM is 64 bit than we do load native .so file from separate location.

Calling System.getProperty(«os.arch») on a 64-bit Linux system (OpenSUSE 11.4) with a 32-bit JVM returns: i386

I used Java(TM) SE Runtime Environment (build 1.6.0_22-b04)

Hi, We have several JDK and JRE installed on Solaris Sparc box, I want to find out which installed JDK or JRE is 64 bit ? Can you please share command to do that ? Also is it possible to run 32 bit JVM in 64 bit machine i.e. if My Solaris sparc box is 64 bit but JVM is 32 bit can I execute Java program there ?

One of the interesting point to know relate to 32 bit or 64 bit installation is that it varies on different environment e.g In windows and Linux you have separate installation for 32 bit and 64 bit JVM but on Solaris machine e.g. Sparc, one JVM installation represent both 32 bit and 64 bit JVM and until specified by -d32 and -d64, they by default run on 32 bit data model. Which means you may not able to assign more than 3.5GB of heap, despite running 64 bit JVM in 64 bit machine. Solution is use -d64 JVM option to run JVM on 64 bit data model.

How do i solve this error:
Could not create the java virtual machine
A fatal exception occurred. program will exit

I got «JVM Bit size: x86» for os.arch and «32bit» for sun.arch.data.model on my intel machine with 64 bit windows 7 os.

Just change the JRE to JDK 1.7.0_17, you will get the 64 bit JVM.

A nice tutorial on
JVM Architecture Specification Basic The Heap Area Introduction, teach about the JVM Heap Area in details
http://www.youtube.com/watch?v=c-A7ZzxjWUI

JVM Architecture Specification Basic The Method Area explained, teach about the JVM method area
http://www.youtube.com/watch?v=a5GzF2fSSCE

As this question is already answered and explained by Java geeks , I just want to add little extra in it — generally people prefer to switch over 64 but JVM when the existing heap space (1.5 to 1.8 M varies OS to OS) size provided by 32 bit JVM is not suffice for their application , but these days it is very common that people are migrating to 64 bit without understanding the requirement of applications.

Источник

Difference Between 32-bit and 64-bit JVM in Java

One does not need to know the difference unless developing a performance-critical application. The minor distinction between 32-bit and 64-bit JVMs would make little difference in your application.

Now coming onto the differences where we will be listing out some key differences between 32-bit and 64-bit Java Virtual Machines are listed below in which we are comparing them alongside based on the concessive factors which are as follows:

1. In a 64-bit JVM, you can specify more memory for heap size than in a 32-bit JVM; for example, in a 32-bit JVM, the theoretical maximum memory limit is 4GB, whereas 64-bit is much higher.
2. The 64-bit JVM is especially useful for Java applications with large heaps, such as those that use more than 100 GB of memory as a maximum.
3. Because the size of the OOP (Ordinary Object Pointer) has increased from 32 to 64 bits, the same Java application will use more memory in the 64-bit JVM than in the 32-bit JVM. You can get away with it if you use the JVM option -XXCompressedOOP, which tells JVM to use 32-bit pointers.
4. The next major change which is seen is that in the 64-bit JVM architecture is the object header size, which is now 12 bytes instead of 8 bytes in the 32-bit JVM. Another change is the size of internal references, which can now be up to 8 bytes, whereas the 32-bit JVM can only be up to 4 bytes.
5. There is a separate installer for the 32-bit and 64-bit JVM’s.
6. Client JVM is only available for 32-bit JVM and not for 64-bit.

As above, we have seen such differences but do remember a note on how can 64-bit JVM performance be slower than 32-bit JVM?

This is because each native pointer in the system takes up eight bytes instead of four. The loading of this additional data increases memory usage, which results in slightly slower execution depending on how many pointers are loaded during your Java program’s execution. The Java virtual machine gains some extra registers that it can use to create more efficient native instruction sequences. When comparing 32-bit to 64-bit execution speed, these extra registers increase performance to the point where there is often no performance loss at all.

Certain points are there to be taken into consideration while migrating from a 32-bit JVM to a 64-bit JVM are as follows:

Factor 1: GC Pause times

The primary motivation for switching from 32-bit to 64-bit JVM is to increase heap size (i.e. -Xmx). When you increase heap size, your GC pause times will automatically increase because there is no more garbage in memory to clear. Before performing the migration, you must perform proper GC tuning; otherwise, your application may experience a pause of several seconds to a few minutes. To come up with the right GC settings for the newly increased heap size, you can use tools like GCeasy.

Factor 2: Native Library

If your application accesses native libraries through the Java Native Interface (JNI), you’ll need to upgrade the native libraries as well because only 32-bit native libraries can be used by 32-bit JVM. Similarly, a 64-bit JVM can only use native libraries that are 64-bit.

• If your application’s heap size (i.e. -Xmx) is less than 2GB, it’s a no-brainer. Use a 32-bit JVM. (< 2GB Memory)
• If your application requires more than 2GB of memory, it’s a no-brainer. Definitely go with 64-bit JVM (> 2GB memory)

Let us now see the differences in a tabular form that are as follows:

32-bit JVM	64-bit JVM
In 32-bit JVM we can have less memory for heap size than in 64-bit JVM.	In 64-bit JVM we can specify more memory for heap size than in 32-bit JVM.
The limit for maximum memory in 32-bit is useful for 4G connectivity.	It is particularly useful for java applications with large heaps.
It has its own installer.	It has an installer different from the 32-bit JVM.
The header size of 8 bytes.	The header size of 12 bytes.
The size of internal references is 4 bytes.	The size of internal references is 8 bytes.

Источник