Size of java primitives on 32/64 bit jvm?

Question

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

Solution 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.

Solution 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)

Solution 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.

Solution 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.)

Solution 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.

View more solutions

Comments

[Rekha]

@joachinm i still find any answer convincing . Can some please help

[yfklon]

if you interested almost 4 years later, you may want to look at stackoverflow.com/questions/23120811/…

[cHao]

Actually, from reading the specs, it looks like they devote a page to specifying that long and double are not inherently atomic. Which would imply that everything else is. Particularly when they discuss the treatment of 64-bit values being read as "two parts" (ie: two independent, but individually atomic, 32-bit reads). Now, ints being atomic doesn't mean they're synchronized with everything else...but a read will read 32 bits, and a write will write 32 bits, all at once.

[mikera]

This answer is not correct - int and all other primitives <= 32 bits are guaranteed to be atomic in any JVM (whether 32bit or 64 bit). Longs and doubles are not guaranteed to be atomic, but can be (and I believe are on most 64-bit JVMs)

[brettw]

@mikera thanks for pointing that out ... updated for correctness.

[Vishy]

BTW: its not guaranteed that access to long and double are not atomic. You can write a program which appears to work every time on one architecture and runs correctly for years, but later fails due to some change (like version of Java or using different hardware)

[cHao]

@PeterLawrey: It's extremely rare that an error occurs due to something being atomic when you expect it not to be -- and those errors would be related to something hardwareish like MMIO (which doesn't exist in Java.) In applications, it's always the other way around. So if you assume the worst there, then the worst that happens is your app works. :)

[oᴉɹǝɥɔ]

Here is clarification from Oracle for JVM implementations: docs.oracle.com/javase/specs/jls/se8/html/jls-17.html