FWIK Java can run on 64-bit system, no problem. I'd like to know how Java support 64-bit features, e.g., System.identityHashCode() returns a 32-bit int, it's common to see the object pointer (memory address) is returned. Should 64-bit Java returns long instead? If not, how would Java scale to 64-bit systems?
-
4This seems more appropriate for StackOverflow.– Adam Lear ♦Commented May 20, 2011 at 3:44
Add a comment
|
2 Answers
FWIK Java can run on 64-bit system, no problem.
Correct.
I'd like to know how Java support 64-bit features.
Java supports 64 bit in a way that introduces no behavioural differences. A Java program will run on 32 bit or 64 bit platforms without change. All of the primitive types are the identical, the class library APIs are identical, the bytecode formats are the same. As far as the program is concerned, the only difference is that you can allocate more things before your heap fills up.
System.identityHashCode() returns a 32-bit int, it's common to see the object pointer (memory address) is returned.
Inaccurate. What you see is a value that may or may not be related to the object's memory address at some time in the object's lifetime. Even if it is a memory address, it can't be used as one. There's no way to turn the int value back into a reference in pure Java. (Even with JNI / JNA it would be highly unreliable ... so don't think about doing it!)
An identity hashcode is a "uniquish" number. That's all.
Should 64-bit Java returns long instead?
No. That would make the class libraries different for 32 bit and 64 bit Java and prevent the same code from running on either platform.
If not, how would Java scale to 64-bit systems?
It just does. There are one or two "issues". For instance array sizes and string lengths are limited to 32-bit int values. These mean that you can't fully exploit the hardware; e.g. you can't arrays with more than 2^31 elements on a 64-bit JVM. (But if you could, there would be compatibility problems between 32 bit and 64 bit JVMs and applications designed to run on the two flavours.)
The identityHashCode return type is not a real issue because the value is NOT guaranteed to be related to machine address, and you can't be used as a machine address either.
-
My brother (bless him), is a BA and asked me how we were going to address the challenge of porting all our Java software to 64bit. Commented May 20, 2011 at 5:01
-
3
-
@Tim, tell him it just is a question of testing your application again with the 64-bit JVM.– user1249Commented May 20, 2011 at 7:56
-
Don't forget you have to double the license fee you pay Oracle for using Java– JaapCommented May 20, 2011 at 10:58
-
@Jaap only if you use the premium VM ( basically JRockit ) And it's not that useful for small servers and no clusters. Commented May 22, 2011 at 23:45
The basic understanding of the JVM is incorrect.
The behaviour of the JVM is very strictly defined in the Java Language Specification and the exact details of the underlying platform is irrelevant as long as the JVM behaves as specified.
Basically you can expect any well-written Java program to run on any JVM, being it 32-bit or 64-bit without any difference in behaviour as the JVM behaves the same.
The primary differences you need to be aware of between 32-bit and 64-bit on the same platform is
- 64-bit JVM's can access much more memory breaking the "around 2 GB"-barrier.
- Memory usage for the same program is somewhat larger on 64-bit than on 32-bit.
In other words, your programs should run unchanged.
Note: If your program happens to use native code you need to consider this a separate, new platform. One example is using Eclipse SWT instead of Swing.