Java Byte Alignment

Generally, Java objects don't require manual byte alignment considerations as the JVM automatically optimizes this during compilation. However, languages like C/C++/C# need careful consideration of object field ordering to avoid wasting space. (Note: This article is based on JDK 1.8)

Object Structure

In the HotSpot JVM, objects in memory are divided into three regions: Header, Instance Data, and Padding.

Object Header

• Mark Word: Contains a series of flag bits, such as lightweight lock flags, biased lock flags, etc. Takes 4 bytes in 32-bit systems and 8 bytes in 64-bit systems.
• Class Pointer: Points to the memory address of the corresponding Class object (its metadata object). Takes 4 bytes in 32-bit systems and theoretically 8 bytes in 64-bit systems (in practice, JVM uses optimization techniques to usually compress the class pointer to 4 bytes).
• Length: For array objects only, there's an additional 4-byte space storing the array length.

Alignment Rules

The 64-bit HotSpot VM reads data in minimum units of 8 bytes, so object sizes must be multiples of 8 bytes, with padding added if necessary.

Experimental Comparison

C/C++

In C/C++, inefficient property ordering in structures can increase the required storage space.

Test Code

​x
1
struct Person1 {
2
    char _char;
3
    int _int;
4
    short _short;
5
};
6

7
struct Person2 {
8
    char _char;
9
    short _short;
10
    int _int;
11
};
12

13
int main() {
14
    printf("_person1 sizeof: %d \n", sizeof(Person1));
15
    printf("_person2 sizeof: %d \n", sizeof(Person2));
16
}

Results

xxxxxxxxxx
2
1
_person1 sizeof: 12 
2
_person2 sizeof: 8 

Therefore, arranging structure properties in a reasonable order is crucial in C/C++ programming. Fortunately, the JVM automatically adjusts property order to ensure minimal object storage space.

Java

Test Code

xxxxxxxxxx
21
1
public class Person {
2
    public char _char;
3
    public int _int;
4
    public short _short;
5
}
6

7
public class Person2 {
8
    public char _char;
9
    public short _short;
10
    public int _int;
11
}
12

13
public static void main(String[] args) {
14
    Person person = new Person();
15
    String s = ClassLayout.parseInstance(person).toPrintable();
16
    System.out.println(s);
17

18
    Person2 person2 = new Person2();
19
    String s2 = ClassLayout.parseInstance(person2).toPrintable();
20
    System.out.println(s2);
21
}

Results

In object memory layout, the JVM optimizes field ordering based on their types and sizes to reduce memory usage and meet alignment requirements. Key observations from the experiment include:

1. Field Order Adjustment: Despite different field declaration orders in Person and Person2 classes, the JVM ultimately adjusts field ordering, prioritizing larger fields (like int _int) to be placed first. This is because:

• Memory Alignment: JVM attempts to combine larger fields with the object header (including Class Pointer) into complete memory blocks (e.g., 8 bytes).
• Padding Reduction: By adjusting field order, smaller fields (like char and short) are combined into the same memory block, minimizing padding bytes.

2. Memory Alignment Rules:

• Field Alignment: JVM aligns fields based on their size - int fields typically require 4-byte alignment, char and short require 2-byte alignment.
• Object Alignment: Total object size is typically a multiple of 8 bytes (for 64-bit systems).
• Padding Bytes: JVM adds padding bytes at the end if the object doesn't meet alignment requirements.

3. Optimization Results for Person and Person2: Regardless of field declaration order, the final memory layout is identical:

• _int is adjusted to the front, forming an 8-byte memory block with the object header.
• _char and _short are combined into the same memory block.
• Padding ensures the total object size is 16 bytes (8-byte aligned).

Additionally, through multiple tests, it's observed that JVM maintains the original property order for fields of the same size during byte alignment, such as long/double, int/float, and byte/boolean pairs.