views:

9703

answers:

5

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.

+17  A: 

Yes, Java bytecode (and source code) is platform independent, assuming you use platform independent libraries. 32 vs. 64 bit shouldn't matter.

Zifre
+4  A: 

No (to the second question; yes to the first), 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.

Tom Hawtin - tackline
You surprise me. I didn't think there was such a thing as 32-bit byte code or 64-bit byte code.
Jon Skeet
Rereading your answer - are you sure you didn't just mean it the other way round? (Yes then no.)
Jon Skeet
+1 to Jon Skeet. I was writing the same comment but got called away.
Michael Myers
I meant no then yes, but with the questions the other way around. Have rolled back an edit and edited (and put a bit more information in).
Tom Hawtin - tackline
@Jon Skeet: there is no 32-bit and 64-bit bytecode, but when JITed the pointers in the JVM are (usually) 32 or 64 bit, depending on the platform. And with Compressed OOPS they can use 32bit pointers in many places, even on 64bit JVMs. That saves quite a bit of memory and increases code locality, thus leading to greater speed.
Joachim Sauer
+6  A: 

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.

Fortyrunner
@Fortyrunner, are you saying that JNI libraries won't work in a 64 bit VM if they're 32 bit?
C. Ross
They didn't in ours. But its been a while since i tried it
Fortyrunner
They don't work. A colleague had reported that they did (which I found suspicious - to say the least). I wondered if he was running on Solaris and that there was some sort of thunking going on. There wasn't; he was mistaken and it was running under 32bit.
Fortyrunner
+3  A: 

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.

Peter Lawrey
+3  A: 

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.

Thorbjørn Ravn Andersen