Size of java primitives on 32/64 bit jvm?

问题:

1. The size of int is 32 bits and long/double are 64 bits. Will these sizes remain same on
   1. 32/64 bit JVM
   2. 32/64 bit processors
2. if yes then will the operations on long/double be atomic on a 64 bit processor/JVM?

The Oracle Java tutorial says:

Reads and writes are atomic for reference variables and for most primitive variables (all types except long and double).

Does this statement has anything to do with jvm/processor architecture? Can someone please explain.

3. Finally will i be able to make read/write of double/long atomic if i use 64 bit jvm and processor

回答1:

Yes, the sizes are the same on both 32-bit and 64-bit JVM. Assignment is not guaranteed to be atomic for either long or double in Java. Atomic assignment, is still no guarantee of visibility from another thread. Because threads are allowed to 'shadow' variables in memory, even atomic assignment to a variable does not necessarily write-thru to main memory (but when main memory is updated, it will be done so atomically). You must always use synchronization barriers of some kind when accessing shared state from two or more threads if you expect one thread to consistently see changes by the other.

回答2:

The only data type which changes size is references. These can be 32-bit or 64-bit. It is a common misconception that references are 64-bit on all 64-bit JVMs and will there for use more memory. On Sun/Oracle Java 6 update 23 and later it became the default to use 32-bit reference provide the heap was less than 32 GB in size.

Note: 64-bit references are atomic, indicating that long and double accesses on those platforms could also be atomic. (Though not guaranteed to be on all systems, esp 32-bit JVMs)

回答3:

According to the JLS:
The integral types are byte, short, int, and long, whose values are 8-bit, 16-bit, 32-bit and 64-bit signed two's-complement integers, respectively, and char, whose values are 16-bit unsigned integers representing UTF-16 code units.

Same goes for float and double.

There's no mention of 32 bit / 64 bit processors / implementation jvm therefore there'll be no modifications wether you're on 32 or 64 bit.

回答4:

int is defined as 32 bits. It won't change with a 64-bit vs 32-bit VM. Same with long -- it's 64 bits, and won't change.

double is a tiny bit tricky. The specs say it's 64 bits wide, so you can count on at least that. Some VMs may use wider numbers internally to do the actual math, but you'll be fine if you always treat a double as a 64-bit number (or if you specify strictfp, which is supposed to ensure the numbers are exactly 64 bits wide, or at least act as if they are).

As for atomicity, that depends somewhat on the platform...but you'll be safe assuming that reads and writes to anything larger than an int are not atomic (unless the variable is marked volatile). And anything that involves reading and then writing the same location is not atomic for any type. (This means ++a; is not inherently atomic.)

回答5:

Sizes of primitives remain the same. On 64 bit processor/jvm the heap sizes are bigger and number of threads which can be used grows.