Will Java code built and compiled against a 32-bit JDK into 32-bit byte code work in a 64-bit JVM? Or does a 64-bit JVM require 64-bit byte code?
To give a little more detail, I have code that was working in a Solaris environment running a 32-bit JVM, but now I'm getting issues after upgrading the JDK and Weblogic Server to 64-bit.
This question is related to
java
jvm
64-bit
compatibility
32-bit
I accidentally ran our (largeish) application on a 64bit VM rather than a 32bit VM and didn't notice until some external libraries (called by JNI) started failing.
Data serialized on a 32bit platform was read in on the 64bit platform with no issues at all.
What sort of issues are you getting? Do some things work and not others? Have you tried attaching JConsole etc and have a peak around?
If you have a very big VM you may find that GC issues in 64 bit can affect you.
Add a paramter as below in you in configuration while creating the exe
I hope it helps.
thanks...
/jav
yo where wrong! To this theme i wrote an question to oracle. The answer was.
"If you compile your code on an 32 Bit Machine, your code should only run on an 32 Bit Processor. If you want to run your code on an 64 Bit JVM you have to compile your class Files on an 64 Bit Machine using an 64-Bit JDK."
The Java JNI requires OS libraries of the same "bittiness" as the JVM. If you attempt to build something that depends, for example, on IESHIMS.DLL (lives in %ProgramFiles%\Internet Explorer) you need to take the 32bit version when your JVM is 32bit, the 64bit version when your JVM is 64bit. Likewise for other platforms.
Apart from that, you should be all set. The generated Java bytecode s/b the same.
Note that you should use 64bit Java compiler for larger projects because it can address more memory.
Yes to the first question and no to the second question; it's a virtual machine. Your problems are probably related to unspecified changes in library implementation between versions. Although it could be, say, a race condition.
There are some hoops the VM has to go through. Notably references are treated in class files as if they took the same space as ints on the stack. double and long take up two reference slots. For instance fields, there's some rearrangement the VM usually goes through anyway. This is all done (relatively) transparently.
Also some 64-bit JVMs use "compressed oops". Because data is aligned to around every 8 or 16 bytes, three or four bits of the address are useless (although a "mark" bit may be stolen for some algorithms). This allows 32-bit address data (therefore using half as much bandwidth, and therefore faster) to use heap sizes of 35- or 36-bits on a 64-bit platform.
All byte code is 8-bit based. (That's why its called BYTE code) All the instructions are a multiple of 8-bits in size. We develop on 32-bit machines and run our servers with 64-bit JVM.
Could you give some detail of the problem you are facing? Then we might have a chance of helping you. Otherwise we would just be guessing what the problem is you are having.
Unless you have native code (machine code compiled for a specific arcitechture) your code will run equally well in a 32-bit and 64-bit JVM.
Note, however, that due to the larger adresses (32-bit is 4 bytes, 64-bit is 8 bytes) a 64-bit JVM will require more memory than a 32-bit JVM for the same task.
The 32-bit vs 64-bit difference does become more important when you are interfacing with native libraries. 64-bit Java will not be able to interface with a 32-bit non-Java dll (via JNI)
Source: Stackoverflow.com