A colleague mentioned in passing today that Java takes 128 bits to represent a 32bit integer. I couldn't believe him -- I had expected some overhead, but a ratio of 4:1? Really?
He turned out to be right. On a 32bit JVM you need 128 bits for an integer, and for a 64bit machine, you need 224 because the class pointers double in size. Ulp.
The increase in class pointer size means that code running in a 64bit JVM generally needs 70% more memory than its 32bit counterpart. There's a switch you can use on Oracle and IBM JVMs to use compressed pointers (-XX:+UseCompressedOops). I haven't found if there are any side effects to using this.
Find all this information on From Java code to Java heap: Understanding and optimizing your application's memory usage.
He turned out to be right. On a 32bit JVM you need 128 bits for an integer, and for a 64bit machine, you need 224 because the class pointers double in size. Ulp.
The increase in class pointer size means that code running in a 64bit JVM generally needs 70% more memory than its 32bit counterpart. There's a switch you can use on Oracle and IBM JVMs to use compressed pointers (-XX:+UseCompressedOops). I haven't found if there are any side effects to using this.
Find all this information on From Java code to Java heap: Understanding and optimizing your application's memory usage.
