Memory alignment in C, C++ and Java
by
Join the DZone community and get the full member experience.
Join For FreeYou might assume that reducing the size of a struct or class saves the same amount of memory. However due to memory alignment in memory allocators it can make no difference, or perhaps more difference than you might expect. This is because the the amount of memory reserved is usually a multiple of the memory alignment. For Java and C this can 8 or 16 bytes.
Size of memory reserved
These tests were performed in a 64-bit C program (gcc 4.5.2) and a 64 JVM (Oracle Java 7) In Java, direct memory is largely a wrapper for malloc and free.| Bytes | C malloc() reserved | Java ByteBuffer.allocateDirect() |
|---|---|---|
| 0 to 24 | 32 bytes | 32 bytes + a ByteBuffer |
| 25 to 40 | 48 bytes | 48 bytes + a ByteBuffer |
| 41 to 56 | 64 bytes | 64 bytes + a ByteBuffer |
| 57 to 72 | 80 bytes | 80 bytes + a ByteBuffer |
Constructing objects is a similar story
| Number of fields | C class of int (heap/stack) | C class of void * (heap/stack) | Java class with int | Java class with Object references |
|---|---|---|---|---|
| 1 | 32/16 bytes | 32/16 bytes | 16 bytes | 16 bytes |
| 2 | 32/16 bytes | 32/16 bytes | 24 bytes | 24 bytes |
| 3 | 32/16 bytes | 32/32 bytes | 24 bytes | 24 bytes |
| 4 | 32/16 bytes | 48/32 bytes | 32 bytes | 32 bytes |
| 5 | 32/32 bytes | 48/48 bytes | 32 bytes | 32 bytes |
| 6 | 32/32 bytes | 64/48 bytes | 40 bytes | 40 bytes |
| 7 | 48/32 bytes | 64/64 bytes | 40 bytes | 40 bytes |
| 8 | 48/32 bytes | 80/64 bytes | 48 bytes | 48 bytes |
Using a C struct/class on the stack is more efficient than the other approaches for a number of reasons, two of them being that there is no memory management header and no additional pointer/reference (not shown in the table).
Sun/Oracle and OpenJDK 6 and 7 JVMs will use 32-bit references and the 8 byte memory aligned and to support up to 32 GB (8 * 4 G) Most JVMs are less than 32 GB in size making this a useful optimisation. Note: Part of the reason that JVMs are usually 1 to 4 GB in size is that the worst case Full GC time is typically 1 second per GB of heap and a 30 second full CG time is to long for most applications. The typical way around this full GC time problem is to keep the working size of the heap to a few GB and use an external database or heapless "direct" and "memory mapped" memory.
Another solution for Java is to use a pause less concurrent collector such as that provided by Azul. They claim excellent scalability beyond 40 GB of heap, but don't openly list their costs ;)
Why does this matter?
Say you have a class like this
class MyClass {
int num;
short value;
}
In C, how much memory is saved by changing num to a short or how much more is consumed of with make it long long. The answer is likely to be none at all (unless you have an array of these) In Java, it could make a difference as the alignment size is different. Conversely, if the C class/struct is 16 or 17 bytes, it can make the size on the stack be 16 or 32 bytes. Similarly being 24 or 25 bytes can make the malloc'ed size used 32 or 48 bytes long.
The code
MemoryAlignment/main.cpp and MemoryAlignment.java
From http://vanillajava.blogspot.com/2011/09/memory-alignment-in-c-c-and-java.html
Opinions expressed by DZone contributors are their own.
Comments