Memory alignment in C, C++ and Java

DZone 's Guide to

Memory alignment in C, C++ and Java

· Java Zone ·
Free Resource

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
C class of void *
 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.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}