Java: All about 64-bit programming

 I found this article series very interesting All about 64-bit programming in one place which collects "a lot of links on the topic of 64-bit C/C++ software development." However some of these issues are relevant to Java and can make a difference.

The size_t in C++ is 64-bit

Java uses the int type for sizes and this doesn't change in a 64-bit JVM. This gives backward compatibility but limits arrays, collections and ByteBuffer's to this size. Generally 2 billion is enough, but as files sizes and memory sizes get larger, the number of situations where it is not will grow over time.

As of mid 2011, for £1K you can buy a PC with 24 GB of memory and for £21K you can buy a server with 512 GB of memory.

This is already a problem for memory mapping a file larger than 2 GB. This can only be done by mapping in a 2 GB window of memory (2^31-1 bytes at a time). This is rather ugly and removes one of memory mapping's key features; transparency.

BTW: I have tried using the underlying library directly using reflection which supports `long` lengths and I could get this working for reading files larger than 2 GB, but not writing.

x64 has more registers than x86

This is be a small advantage. If you are performing a lot of operations using long I have seen about 10% performance improvement.

64-bit JVM can access more memory

This is essential if you need more than 1.2-3.5 GB of memory (depending on the OS). The downside is 64-bit references can increase memory usage and slow performance.

One way to use a 64-bit JVM efficiently is to use the -XX:+UseCompressedOops which uses 32-bit references in a way which can still access 32 GB of memory. It can do this because every object in the Sun/Oracle JVM is allocated on a 8-byte boundary (i.e. the lower 3 bits of the address are 000) By shifting the bits of the 32-bit reference, it can access 4GB * 8 or 32 GB in total. It has been suggested that this should be the default for Java 7.

Link: What 64-bit systems are.

Support for 32-bit programs

Programs written and compiled for a 32-bit JVM will work without re-compilation. However any native libraries used will not. A 64-bit JVM can only load 64-bit native libraries.

Switching between int and long

The int and long types work the same on a 32-bit and 64-bit JVM however if you switch code between int and long you can get some issues.

Long literals may need an ell

With all int literals you can just use the number

int i = 123456789;
long j = 123456789;

However for large numbers an L is required.

long i = 111111111111111L; // a long literal.
long j = 111111111111111l; // using `l` is discouraged as it looks like a 1.

If you have a calculated values you may need to use L

long i = 1 << 40; // i = 256!
long i = 1L << 40; // i = 2^40

The shift operator only takes the lower 5 bits of the shift for 32-bit numbers, and 6 bits for 64-bit values. So the first line is like

long i = 1 << (40 % 32);

Shifting puzzle

A puzzle for you. ;) What does this do for a 32-bit and 64-bit for x?

sign = x >> -1;

64-bit references and Object size

When using 64-bit references, the size of a reference doubles. In the Sun/Oracle JVM the header includes a reference. From the Source for Map.Entry

class MapEntry implements Map.Entry, Cloneable {
       K key;
       V value;

In a 32-bit JVM, the header takes 8 bytes, with each reference, this takes 16 byte total.
In a 64-bit JVM with 32-bit references, the header takes 8 + 4 bytes and each reference takes 4 bytes. 8-bytes aligned means it uses (12+4+4 bytes + 4 padding) total: 24 bytes.
With 64-bit references, the header uses 16-bytes and each references uses 8 bytes. (16 + 8 + 8) total: 32 bytes.
For more details read Java: Getting the size of an Object

Conclusion

Migrating from 32-bit to a 64-bit in Java is relatively easy compared with C/C++ however there are some issues you may need to consider when migrating.

From http://vanillajava.blogspot.com/2011/07/java-all-about-64-bit-programming.html