views:

250

answers:

4

Few Questions :):

How to identify what JVM is currently installed ? (64 bit / 32 bit)

Do I need to do some considerations while programming for 64 bit JVM target Platform ?

Can my Java code work on 32 bit as well as 64 bit JVM ?

How to run my Java App on 64 bit JVM ?

How to identify what JVM is being used for my Java App ?

+7  A: 

Normally a 64 bit jvm will identify itself as such.

32/64 bit Considerations I have seen:

  1. address space - if you're not expecting to address more that 1.3Gb of memory then you won't see a difference
  2. native libraries - if you're loading any JNI libs, then they will need to match your VM architecture. For example, don't try loading 32-bit native libraries from a 64-bit vm (without -d32 type of flags)

Yes, the same code will run on both JVMs.

System Property "sun.arch.data.model" has the 32/64 flag I think.

There's some helpful info here: http://www.oracle.com/technetwork/java/hotspotfaq-138619.html

jowierun
Be aware that sun.arch.data.model is non-standard, so non-sun JVM implementations might not provide that system property. The system property os.arch is a standard system property, but you might have to parse it. Checking to see if os.arch contains the characters '64' might work.
Sean Reilly
@jowierun "Normally a 64 bit jvm will identify itself as such."But when I run same on Solaris (where 32 bit as well as 64 VM are installed) it always take 32 bit VM.
YoK
@Sean Reilly but on 64 bit Sparc machine I can run 32 bit JVM. So I don't think os.arch will help.
YoK
@YoK on Solaris you need to give it the -64 options.
Peter Lawrey
@Peter Lawrey is it -64 or -d64 ?
YoK
It's `-d64` actually.
Willi
os.arch will tell you whether the OS is 64 or 32 bit. This does NOT mean the VM is. There may be reasons for running the 32 bit VM on 64 bit machines, e.g. due to JNI libraries. There is AFAIK no portable way to determine whether the current VM is 32 or 64 bit.
Thomas Lötzer
+1 Answer and providing useful link
YoK
@YoK, good point.
Peter Lawrey
+2  A: 

In your own Java code, you don't have to do anything special with regard to 32- or 64-bit. Unlike for example C and C++, an int in Java is always 32 bits and a long is always 64 bits (in C and C++, the size of those types is system-dependent).

There are no separate 32-bit and 64-bit versions of Java bytecode; the bytecode is exactly the same, regardless of the fact that the JVM you might be running it on is 32-bit or 64-bit. You don't have to compile your Java source differently for 32-bit or 64-bit. With regard to functionality it does not matter for your Java application if it runs on a 32-bit or 64-bit JVM.

There might be some technical differences that jowierun already mentioned. There might also be performance differences; for example Oracle's 64-bit JVM for Windows is tuned differently than the 32-bit JVM, it does other JIT optimizations. I noticed this myself with a computation-intensive application that I wrote recently; on a 64-bit JVM it runs much faster than on a 32-bit JVM. (But that's only one example, don't take this as proof that any program runs much faster on a 64-bit JVM).

Jesper
A: 

You have these questions back to front.

  1. You don't have to do anything in your Java code, it will run on both 32-but and 64-bit.
  2. Therefore you don't need to know whether it's a 64 bit JVM or not.
EJP
+1  A: 

If you plan to write native code using the Java Native Interface (JNI), you have to be extra careful on writing proper C code that will run on both 64 and 32 bit machines. Make sure you use proper Java types when passing arguments to/from java code (JNI provides a set of typedefs for java types), especially when converting arrays. And when testing your native code, test on both architectures (-m32 will force a 32 bit arch on GNU gcc) with different JVMs.

lOranger