Does member order make a performance difference in Java like in C or C++?

Question

In C and C++, the compiler is not allowed to reorder data members of structs, so if you're not careful with how you order them, you end up wasting space. For example:

struct S {
    int i;
    void *p;
    int i2;
};

On a platform with 32-bit ints and 64-bit pointers, i will be placed first, followed by 32 bits of padding so that p can be 64-bit–aligned. i2 then takes up half of the next word, followed by another 32 bits of padding. The resulting struct is 24 bytes long, whereas if p were declared first, it would be only 16 bytes long. If you have a lot of these structs in an array, finding and removing the padding can sometimes be an important optimization, to save memory and reduce cache churn.

I'm curious to know if Java has the same feature. Are unboxed types (such as int and boolean) the same size as references or smaller? And if they're smaller, is the compiler allowed to reorder them to avoid inserting padding to align subsequent fields? Finally, if it is, do any compilers do this?

I don't have a particular optimization need for this right now, I'm just curious to know if I should bear this in mind when choosing what order to declare my fields, like I do in C.

Answer 1

int types are always 32-bit and references are usually 32-bit even in 64-bit JVMs.

On the down side, Java has a 8-12 byte header at the start of each object and uses an 8-byte alignment. BTW some C++ environments have a 16-byte alignment.

Are unboxed types (such as int and boolean) the same size as references or smaller?

You can expect them to be smaller for boolean, byte, char and short, but the primitives can be larger for long and double than a reference.

And if they're smaller, is the compiler allowed to reorder them to avoid inserting padding to align subsequent fields?

The JIT can re-organise the fields or even optimise them away.

Finally, if it is, do any compilers do this?

The javac compile does next to no optimisations and looking at the byte code will give you little clues as to what will happen at runtime. The JIT can optimise the fields in an objects anyway it chooses.

I'm just curious to know if I should bear this in mind when choosing what order to declare my fields, like I do in C.

IMHO, You can assume that just about every optimisation trick you might have used in C not longer applies in Java. Of the few that do, they may not be exactly the same.

You should assume the JIT will optimise the code as required and use profilers to determine if and when you have a problem. Only then consider altering the code for performance reasons.

Answer 2

Java does not have structs, only classes. A class in Java doesn't necessarily mean that class is also in C++ backend. You don't even know if the JVM is implemented in C/C++. It can by any other language.

But for the C++ JVMs, I think they try to optimize. Primitive (they are not called unboxed) types, such as int or boolean, usually map to their primitive counterparts (as far as my JNI experience goes), but as there are no structs, they don't need to arrange.

I am almost sure rearraging class fields will not have any impact on memory consumption. Just because they do not map to structs.

Answer 3

In java there is so such issue. The compiler deals with variable declaration, and the programmer has no control on where to allocate them in memory