# Demystifying Java Object Sizes: Compact Headers, Compressed Oops, and Beyond

DevFeed: [Demystifying Java Object Sizes: Compact Headers, Compressed Oops, and Beyond](<https://devfeed.tech/articles/demystifying-java-object-sizes-compact-headers-compressed-oops-and-beyond-30741.md>)

Original publisher: [Read original article](<http://blog.vanillajava.blog/2024/12/demystifying-java-object-sizes-compact.html>)

Author: Peter Lawrey (noreply@blogger.com)

Published: 2024-12-10T16:51:00Z

Content type: article

Language: en

Sources: [Vanilla Java](<https://devfeed.tech/sources/vanilla-java.md>)

Topics: [Java](<https://devfeed.tech/topics/java.md>), [systems](<https://devfeed.tech/topics/systems.md>), [Code](<https://devfeed.tech/topics/code.md>), [Concurrency](<https://devfeed.tech/topics/concurrency.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [gc](<https://devfeed.tech/tags/gc.md>), [info](<https://devfeed.tech/tags/info.md>), [java](<https://devfeed.tech/tags/java.md>), [jvm](<https://devfeed.tech/tags/jvm.md>), [low-latency](<https://devfeed.tech/tags/low-latency.md>), [memory](<https://devfeed.tech/tags/memory.md>), [object](<https://devfeed.tech/tags/object.md>), [opinion](<https://devfeed.tech/tags/opinion.md>), [performance](<https://devfeed.tech/tags/performance.md>), [threads](<https://devfeed.tech/tags/threads.md>)

## AI overview

An article explaining how Java object sizes are affected by Compressed Oops and Compact Object Headers. It describes estimating object sizes with JVM memory measurements, while accounting for TLAB allocation, garbage collection, and concurrent allocations. It also summarizes JEP 450's proposed reduction of object headers to 64 bits on supported 64-bit platforms.

## Source excerpt

Introduction Measuring an object's size in Java is not straightforward. The platform encourages you to consider references and abstractions rather than raw memory usage. Still, understanding how objects fit into memory can yield significant benefits, especially for high-performance, low-latency systems. Over time, the JVM has introduced optimisations like Compressed Ordinary Object Pointers (Compressed Oops) and, more recently, Compact Object Headers. Each of these can influence how large or small your objects appear. Understanding these factors helps you reason about memory usage more concretely. Measuring Object Sizes In principle, you can estimate an object's size by creating instances and observing changes in the JVM's free memory. However, you must neutralise certain factors to get consistent results. For example, turning off TLAB allocation (-XX:-UseTLAB) makes memory usage more directly observable. Repeated measurements and median calculations can reduce the impact of GC and concurrent allocations. A GC can occur while you are creating your object. This will result in more free memory at the end than when you started. I ignore any negative sizes in this test ;) Other threads in the system could use memory at the same time. I perform multiple test and take the median, which removes any outliers. Below is a rough approach: long before = usedMemory(); Object obj = createYourObject(); long after = usedMemory(); long approximateSize = after - before; This test SizeofTest.java is a simple test which creates a number of objects and measures the memory used to create each object. This is usually the same as the amount of memory the object retains for simple objects. Approximate layout of an object Memory Region Description Size (Bytes) Mark Word Header information including identity hash code, lock state, and GC metadata 8 bytes (on 64-bit JVMs) Class Pointer (Klass Pointer) Reference to the object's class metadata, used internally by the JVM Typically 4 bytes with C