Peter is a DZone MVB and is not an employee of DZone and has posted 161 posts at DZone. You can read more from them at their website. View Full User Profile

Java: All about 64-bit programming

07.13.2011
| 12438 views |
  • submit to reddit

 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

Published at DZone with permission of Peter Lawrey, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Artur Biesiadowski replied on Thu, 2011/07/14 - 5:18am

Are you sure about object header taking 12 bytes in 32-bit Sun JVM? I always got impression it was 8 bytes (class pointer and combined monitor/hashcode/gc bits word). Maybe you confused it with arrays, where there is additional length field in header?

Peter Lawrey replied on Sun, 2011/07/17 - 2:36am in response to: Artur Biesiadowski

Thats a good question.  I have written an article on the size of objects and headers and how you can measure them http://vanillajava.blogspot.com/2011/07/java-getting-size-of-object.html

In short, on the Sun/Oracle JVM, the 32-bit JVM uses 8-bytes for the header, the 64-bit JVM with 32-bit references has a 12-byte header and with 64-bit references has a 16 bytes header.

 I will update my original to make this distinction clearer.

 Thank you.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.