I'm fairly familiar with the layout of objects on the heap in HotSpot, but not so much for Android.
For example, in a 32-bit HotSpot JVM, an object on the heap is implemented as an 8-byte header, followed by the object's fields (one byte for boolean
, four bytes for a reference, and everything else as expected), laid out in some specific order (with some special rules for fields from superclasses), and padded out to a multiple of 8 bytes.
I've done some research, but I can't find any Android-specific information.
(I'm interested in optimizing some extremely widely used data structures to minimize memory consumption on Android.)
dalvik/vm/oo/Object.h
is your friend here. The comment forstruct Object
says:java.lang.Class
objects are special; their layout is defined by theClassObject
struct inObject.h
. Array objects are simple:For arrays, the widths are in
vm/oo/Array.cpp
. Booleans are width 1, objects havesizeof(Object*)
length (usually 4), and all other primitive types have their expected (packed) length.Data objects are really simple:
The layout of a
DataObject
(all non-Class class instances) is governed bycomputeFieldOffsets
invm/oo/Class.cpp
. According to the comment there:So, superclass fields come first (as usual), followed by reference-type fields, followed by a single 32-bit field (if available, and if padding is required because there's an odd number of 32-bit reference fields) followed by 64-bit fields. Regular 32-bit fields follow. Note that all fields are 32-bit or 64-bit (shorter primitives are padded). In particular, at this time, the VM does not store byte/char/short/boolean fields using less than 4 bytes, though it certainly could support this in theory.
Note that all of this is based on reading the Dalvik source code as of commit
43241340
(Feb 6, 2013). Since this aspect of the VM doesn't appear to be publically documented, you should not rely on this to be a stable description of the VM's object layout: it may change over time.