# The real size of Android objects 📏

DevFeed: [The real size of Android objects 📏](<https://devfeed.tech/articles/the-real-size-of-android-objects-25864.md>)

Original publisher: [Read original article](<https://dev.to/pyricau/the-real-size-of-android-objects-1i2e>)

Author: Py ⚔

Published: 2020-09-22T22:31:08Z

Content type: tutorial

Language: en

Sources: [Py ⚔](<https://devfeed.tech/sources/py.md>)

Topics: [Android](<https://devfeed.tech/topics/android.md>), [Java](<https://devfeed.tech/topics/java.md>), [Android Studio](<https://devfeed.tech/topics/android-studio.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [coding](<https://devfeed.tech/tags/coding.md>), [community](<https://devfeed.tech/tags/community.md>), [deep-dive](<https://devfeed.tech/tags/deep-dive.md>), [development](<https://devfeed.tech/tags/development.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [inclusive](<https://devfeed.tech/tags/inclusive.md>), [java](<https://devfeed.tech/tags/java.md>), [leakcanary](<https://devfeed.tech/tags/leakcanary.md>), [memory](<https://devfeed.tech/tags/memory.md>), [performance](<https://devfeed.tech/tags/performance.md>), [software](<https://devfeed.tech/tags/software.md>)

## AI overview

The article investigates why Android and other heap-dump tools report different shallow object sizes. It explains that Java virtual machines use different memory layouts and that HPROF instance sizes are independent of VM layout and padding. Because JOL does not run on Dalvik or ART, the author explores using ART TI and its GetObjectSize API for LeakCanary.

## Source excerpt

Header image: Deep Dive by Romain Guy. I'm currently reimplementing how LeakCanary computes the retained heap size of objects. As a quick reminder: Shallow heap size of an object: The object size in the memory. Retained heap size of an object: The shallow size of that object plus the shallow size of all the objects that are transitively held in memory by only that object. In other words, it's the amount of memory that will be freed when that object is garbage collected. One cannot trust a shallow size As part of that work, I compared the shallow size of objects as reported in LeakCanary versus other heap dump tools such as YourKit, Eclipse Memory Analyzer Tool (MAT) and Android Studio Memory Analyzer. That's when I realized something was wrong: every tool provides a different answer. I asked Jesse Wilson about it and he pointed me to this article by Aleksey Shipilёv: What Heap Dumps Are Lying To You About. Some take aways: Every Java VM lays out its memory in a slightly different way and performs various optimizations, such as changing field order, aligning bits, etc. The heap dump format (.hprof) is a standard. A class dump record contains the list of fields and their types as well as the instance size of the class. Aleksey Shipilёv asked about having the instance size be the actual size of an instance in memory but the answer was nope: the sizes in the HPROF dump are VM and padding independent, to avoid breaking expectations from consuming tools. There's a tool called JOL that instruments the JVM runtime to report the actual size of an object. Aleksey used that to compare the size reported in hprof based tools with the actual size and found that they were all wrong in a different way. In Exploring Java's Hidden Costs, Jake Wharton showed how to use JOL. Unfortunately, JOL only runs on JVMs, and not the Dalvik or ART runtimes. To quote Jake: In this case, because the classes are exactly the same and the JVM 64 bit, and Android's now 64 bit, the number should be tra