What Is the Memory Consumption of an Object in Java

How to know how much memory our object uses?

You can't. You can only do some very rough estimates. It depends on the version of your JRE.

• Every instance has a minimum memory footprint for management information like a reference to the defining class, maybe 16 bytes.
• For every instance field, add the "size" of that field, plus some padding if the field type is shorter than the default alignment used in your JRE.
• A class is an instance of the class named Class, having a lot of internal fields and data structures, besides the fields declared static. And it "holds" the bytecode of the methods defined there and any compiled native method versions from the HotSpot Just-In-Time compiler. So it's close to impossible to estimate the memory consumption of adding a new class to a JRE.
• A string literal like "Sambhav" adds one String instance to the constants pool if it isn't already present there. And a String instance has at least a length field and an array holding the characters. The internal details have changed with various versions of JRE.

Now analyzing your Utils class snippet:

• You only have the class, no instance. So, add the (unknown) memory footprint of the class to your calculation.
• Your user code needs one String literal that's probably not yet present in the constant pool. So, add two instances to your calculation, one String instance plus one character-holding array, with the array's footprint of course depending on the string length.

What actually memory overhead is in java?

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.

Related Topics