Memory alignment in C, C++ and Java

Overview

You 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