Aleksey Shipilёv, @shipilev, aleksey@shipilev.net
This is an updated version of the Russian post I had roughly one year ago, way before Java Object Layout was available under OpenJDK, and the draft I had on GitHub was in infancy. The rationale for this post is to give the "runtime guy" perspective on every single blog post about Java object sizes and layouts.
Part I. Myths
Myth 0. You can figure out the object size once and for all
In reality, it depends on number of things. Target VM: what exactly you are running with? HotSpot? JRockit? J9? ahem Dalvik? Platform bitness: reference sizes are probably different, or even the basic types take a different number of bytes. Potential and actual optimizations, a la object inlining, scalarized fields, paddings, etc.
Myth 1. It is enough to sum up the field sizes to get the instance size
In reality, VMs are free to choose the representation for the basic types. Moreover, VMs are even forced to widen the representation beyond necessary for values domain in order to maintain basic language semantics (e.g. read/write atomicity) or to fit the underlying hardware requirements (e.g. always do aligned accesses). Moreover, the objects themselves also need to be aligned to maintain the field alignments intact. And then there are object headers…
Myth 2. It is enough to sum up the field sizes, PLUS the well-known header size
In reality, this data has questionable "shelf life", because VMs are free to choose the object representations, including the headers format. For example, current HotSpot can have the header sizes from 8 to 16 bytes in different conditions. JRockit will mostly have 8 bytes headers. That will change once HotSpot adopts the same object header format (that requires significant rework in locking schematics though).
Myth 3. Any sensible tool will show up correct instance size
In reality, it depends. HPROF will dump the instance size as calculated in Myth 1. That means, every single tool using HPROF (e.g. jhat, Eclipse MAT, VisualVM, Yourkit) as the source data is doomed to under/overestimate instance sizes, because they are forced to guess.
The moral here: we need online tools, which will give the instance size info on the spot.
Part II. Reality
The significant trouble for offline tools is HPROF format itself. HPROF is so "VM agnostic" that you don’t even know if you have been running 32- or 64-bit VM (yeah, there is "ID size", but is it really the reference size?). Good luck knowing if compressed references enabled or not. Forget about field layouts info, and object headers either, this info is completely lost. You only have the bitscale of instance field data with the class data describing what particular bits mean there. Hence, tools parsing HPROF need to guess the runtime layout of the objects.
Offline tools shootout
Let’s illustrate this last point. Make up some class, have a single instance of it, do the heapdump, and open the dump in various tools. Here’s our specimen for today:
public class Main {
private static Object obj;
public static void main(String[] args) throws Exception {
obj = new D();
System.in.read();
}
static class A {
long a;
}
static class B extends A {
boolean b;
}
static class C extends B {
int c;
}
static class D extends C {
boolean d;
}
}Now, we can get a few heap dumps in various modes. For the sake of completeness, here is the exact environment the data is gathered. For today’s experiment, I downloaded the latest and greatest revisions of the tools available, as well as some of the recent JDKs:
-
Linux x86_64, 3.12+
-
HotSpot 24.0-b56, JDK 7u40
-
JRockit R28.2.5-20-152429-1.6.0_37-20120927-1915-linux-*, JDK 6u37
-
Visual VM 1.3.6
-
Eclipse Memory Analyzer Tool 1.3.0.20130517
-
YourKit Profiler 2013 (build 13066), evaluation license
This is what we get:
| VM | Bitness | CompRef | Main$D instance size, bytes |
||
|---|---|---|---|---|---|
VisualVM |
Eclipse MAT |
YourKit |
|||
HotSpot (7u40) |
x86 |
no (N/A) |
22 |
32 |
32 |
HotSpot (7u40) |
x86_64 |
yes (default) |
30 |
32 |
40 |
HotSpot (7u40) |
x86_64 |
no |
30 |
48 |
48 |
JRockit (6u37) |
x86 |
no (N/A) |
22 |
32 |
32 |
JRockit (6u37) |
x86_64 |
yes (default) |
30 |
32 |
40 |
JRockit (6u37) |
x86_64 |
no |
30 |
48 |
48 |
You can easily see the tools are disagreeing with each other on number of things, and that is because tools are forced to guess. In order to get the true runtime object layout, we need some heavy artillery. You can actually use Unsafe to get the field layout in the object, read the field values there, deduce the basic type lengths, object alignment, etc. We already did that in Java Object Layout (JOL), which significantly shortens this post.
Exploring specimens with JOL
Let us start with HotSpot. You can see different things there:
-
HotSpot has 8-byte, 12-byte, and 16-byte object headers. This is because the header contains two parts, markword (metainfo about the object), and classword (the reference to class). In 32/64-bit mode markword takes up either 4 or 8 bytes. Classword is "just" the reference, and hence it can be compressed in 64-bit mode.
-
The objects are aligned by 8 bytes. This is required to maintain the field alignments, although pessimistic. The object itself has the trailing gap, where nothing else could be allocated, since next object should also be aligned by 8 bytes
-
C.cis aligned by 4 bytes, andA.ais aligned by 8 bytes. There are substantial number of gaps between the fields because of these aligments
My research on how we can improve this layout scheme can be found here.
Running 32-bit HotSpot VM.
Objects are 8 bytes aligned.
Main.D object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 8 (object header) N/A
8 8 long A.a N/A
16 1 boolean B.b N/A
17 3 (alignment/padding gap) N/A
20 4 int C.c N/A
24 1 boolean D.d N/A
25 7 (loss due to the next object alignment)
Instance size: 32 bytes
Running 64-bit HotSpot VM.
Objects are 8 bytes aligned.
Main.D object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 16 (object header) N/A
16 8 long A.a N/A
24 1 boolean B.b N/A
25 7 (alignment/padding gap) N/A
32 4 int C.c N/A
36 4 (alignment/padding gap) N/A
40 1 boolean D.d N/A
41 7 (loss due to the next object alignment)
Instance size: 48 bytes
Running 64-bit HotSpot VM.
Using compressed references with 3-bit shift.
Objects are 8 bytes aligned.
Main.D object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 12 (object header) N/A
12 4 (alignment/padding gap) N/A
16 8 long A.a N/A
24 1 boolean B.b N/A
25 3 (alignment/padding gap) N/A
28 4 int C.c N/A
32 1 boolean D.d N/A
33 7 (loss due to the next object alignment)
Instance size: 40 bytes
And this is JRockit:
-
Note that it has the same header size in all VM modes. That will confuse tools a lot.
-
Other than that, it suffers from the same losses as the HotSpot.
Running 32-bit JRockit (experimental) VM.
Objects are 8 bytes aligned.
Main.D object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 8 (object header) N/A
8 8 long A.a N/A
16 1 boolean B.b N/A
17 3 (alignment/padding gap) N/A
20 4 int C.c N/A
24 1 boolean D.d N/A
25 7 (loss due to the next object alignment)
Instance size: 32 bytes
Running 64-bit JRockit (experimental) VM.
Using compressed references with 0-bit shift.
Objects are 8 bytes aligned.
Main.D object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 8 (object header) N/A
8 8 long A.a N/A
16 1 boolean B.b N/A
17 3 (alignment/padding gap) N/A
20 4 int C.c N/A
24 1 boolean D.d N/A
25 7 (loss due to the next object alignment)
Instance size: 32 bytes
Running 64-bit JRockit (experimental) VM.
Objects are 8 bytes aligned.
Main.D object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 8 (object header) N/A
8 8 long A.a N/A
16 1 boolean B.b N/A
17 3 (alignment/padding gap) N/A
20 4 int C.c N/A
24 1 boolean D.d N/A
25 7 (loss due to the next object alignment)
Instance size: 32 bytes
Tools shootout (updated)
Now that we have the reference point, we can update the table:
| VM | Bitness | CompRef | Main$D instance size, bytes |
|||
|---|---|---|---|---|---|---|
VisualVM |
Eclipse MAT |
YourKit |
JOL |
|||
HotSpot (7u40) |
x86 |
no (N/A) |
22 |
32 |
32 |
32 |
HotSpot (7u40) |
x86_64 |
yes (default) |
30 |
32 |
40 |
40 |
HotSpot (7u40) |
x86_64 |
no |
30 |
48 |
48 |
48 |
JRockit (6u37) |
x86 |
no (N/A) |
22 |
32 |
32 |
32 |
JRockit (6u37) |
x86_64 |
yes (default) |
30 |
32 |
40 |
32 |
JRockit (6u37) |
x86_64 |
no |
30 |
48 |
48 |
32 |
We can see there are no ideal tools for the job. And don’t get me wrong: both MAT and YourKit are really trying! This is not the failure of the tools, this is the failure of VM protocol which could not possibly communicate the layout information to the tools reliably. When the tools are running inside the VM themselves, they could get the precise layout info, just like JOL did.
Part III. Going Deeper
Sad part
The layout gaps are actually quite rare to confuse tools. Most of the time VMs are very good at packing the field data densely, so that easy sum over the field sizes is enough to somewhat accurately account for the instance sizes. However, this might change at any moment. Consider, for example, the class which uses @Contended:
public static class ContendedTest {
@Contended private int int1;
private int int2;
}The very effect of @Contended is to isolate the int1 field from all other fields. This yields the drastically different layout:
Running 64-bit HotSpot VM.
Using compressed references with 3-bit shift.
Objects are 8 bytes aligned.
ContendedTest object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 12 (object header) N/A
12 4 int ContendedTest.int2 N/A
16 128 (alignment/padding gap) N/A
144 4 int ContendedTest.int1 N/A
148 128 (alignment/padding gap) N/A
276 4 (loss due to the next object alignment)
Instance size: 280 bytes
…and all the HPROF-based tools would happily report something around 24 bytes for the instance, while the actual size is ten times larger! There is no way for HPROF to convey this kind of info.
Happy part
But in the end, we can sometimes use this knowledge to our own benefit. We can add fields ninja-style to the existing classes without increasing the percieved instance sizes! Like this:
public class A {
boolean a;
}
public class NinjaA {
boolean a;
boolean b, c, d; // can add these
}
No increase in instance size, "hiding" the fields in the alignment shadow:
Running 64-bit HotSpot VM.
Using compressed references with 3-bit shift.
Objects are 8 bytes aligned.
A object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 12 (object header) N/A
12 1 boolean A.a N/A
13 3 (loss due to the next object alignment)
Instance size: 16 bytes
Running 64-bit HotSpot VM.
Using compressed references with 3-bit shift.
Objects are 8 bytes aligned.
NinjaA object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 12 (object header) N/A
12 1 boolean NinjaA.a N/A
13 1 boolean NinjaA.b N/A
14 1 boolean NinjaA.c N/A
15 1 boolean NinjaA.d N/A
Instance size: 16 bytes
Part IV. Epilogue
TL;DR:
-
Most of the HPROF-based tools have problems with deducing the actual instance footprint; the special crafted example in this article shows >25% difference between actual and estimated instance size, which can lead the analysis in the wrong direction. However, the cases like that are rare, and most analyses should be fine, especially when dealing with gigabytes worth of memleaks.
-
There were talks to get HPROF fixed up, but they winded down with the bottom-line "we just need a better format", because tools already have reservations about what HPROF actually means. JEP, anyone?
-
Online tools are the best to figure out actual instance footprint. Use JOL, run it via command-line, embed it into your projects. Don’t you ever, ever guess the object layouts by looking at the heap dumps.
-
If you are interested in more examples, you may want to look through the runnable Code Samples shipped with JOL itself.