What actually memory overhead is in java?

Question

I have read what-is-the-memory-consumption-of-an-object-in-java and what-is-the-memory-overhead-of-an-object-in-java.

But still I am in confusion.

• What is memory overhead?? is it the padding?
• What is JVM with compressed pointers? is it reference??
• If 32-bit JVM is used then overhead will be less? Ofcourse yes.But is it because of padding?
• So is it better to use always 32-bit JVM for memory efficiency or for performance?

Below image is from this link(page no.26)

In this image at starting itself they shown as 16 bytes JVM overhead,why that so??

Answer 1

What is memory overhead??

When more memory is used than the fields you created.

is it the padding?

Some is padding which can appear anywhere in the object, except the header which is always at the start. The header is typically 8-12 bytes long.

What is JVM with compressed pointers?

A technique for using 32-bit pointers in a 64-bit JVM to save memory.

is it reference??

References can use this technique but so can pointers to the class information for an object.

If 32-bit JVM is used then overhead will be less?

Possibly, though this is the same as using compressed pointers for references and classes.

But is it because of padding?

It's because 64-bit pointers use more space than 32-bit pointer.

So is it better to use always 32-bit JVM for memory efficiency or for performance?

No, the 32-bit processor model has 32-bit registers where as the 64-bit model has twice as many registers which are double the sized (64-bit) means far more can be held in the fastest memory, the registers. 64-bit calculations tend to be faster as well with a 64-bit processing model.

In general I would recommend you always use the 64-bit JVM unless you a) can't or b) have a very small amount of memory.

In this image at starting itself they shown as 16 bytes JVM overhead,why that so??

This is not strictly correct. This assumes you have a non compressed class reference so the header is 12-bytes, however objects are 8 byte aligned by default, which means there will be 4 bytes of padding at the end (which totals 16 bytes but it's not all at the start)

FAQ: Why can 32-bit Compressed OOP address more than 4 GB

Object have to be 8-byte aligned by default. This makes memory management easier but wastes some padding sometimes. A side effect is that the address of every object will have 000 for the lowest three bits (it has to be a multiple of 8) Those bits don't need to be stored. This allows a compressed oops to address 8 * 4 GB or 32 GB.

With a 16 byte object alignment the JVM can address 64 GB with 32-bit reference (however the padding overhead is higher and might not be worth it)

IFAQ: Why is it slower at around 28 - 32 GB

While the reference can be multiplied by 8, the heap doesn't start at the start of memory. It typically start around 4 GB after. This means that if you want the full 32 GB you have to add this offset, which has a slight overhead.

Heap sizes:

• < 4 GB - zero extend address
• 4 - 28 GB - multiply by 8 or << 3 note: x64 has an instruction for this to support double[] and long[]
• 28 - 32 GB - multiple by 8 and add a register holding the offset. Slightly slower, but not usually a problem.