dalvik/vm/oo/Object.h अपने दोस्त यहाँ है। struct Object के लिए टिप्पणी कहते हैं:
/*
* There are three types of objects:
* Class objects - an instance of java.lang.Class
* Array objects - an object created with a "new array" instruction
* Data objects - an object that is neither of the above
*
* We also define String objects. At present they're equivalent to
* DataObject, but that may change. (Either way, they make some of the
* code more obvious.)
*
* All objects have an Object header followed by type-specific data.
*/
java.lang.Class वस्तुओं विशेष कर रहे हैं; उनके लेआउट को संरचना Object.h में परिभाषित किया गया है। सरणी वस्तुओं सरल हैं:
struct ArrayObject : Object {
/* number of elements; immutable after init */
u4 length;
/*
* Array contents; actual size is (length * sizeof(type)). This is
* declared as u8 so that the compiler inserts any necessary padding
* (e.g. for EABI); the actual allocation may be smaller than 8 bytes.
*/
u8 contents[1];
};
सरणियों के लिए, चौड़ाई vm/oo/Array.cpp में हैं। बूलियन चौड़ाई 1 हैं, वस्तुओं में sizeof(Object*) लंबाई (आमतौर पर 4) होती है, और अन्य सभी आदिम प्रकारों की उनकी अपेक्षित (पैक) लंबाई होती है।
डाटा वस्तुओं वास्तव में सरल हैं:
/*
* Data objects have an Object header followed by their instance data.
*/
struct DataObject : Object {
/* variable #of u4 slots; u8 uses 2 slots */
u4 instanceData[1];
};
एक DataObject (सभी गैर-कक्षा वर्ग उदाहरण) के लेआउट vm/oo/Class.cpp में computeFieldOffsets द्वारा नियंत्रित है। वहाँ टिप्पणी के अनुसार:
/*
* Assign instance fields to u4 slots.
*
* The top portion of the instance field area is occupied by the superclass
* fields, the bottom by the fields for this class.
*
* "long" and "double" fields occupy two adjacent slots. On some
* architectures, 64-bit quantities must be 64-bit aligned, so we need to
* arrange fields (or introduce padding) to ensure this. We assume the
* fields of the topmost superclass (i.e. Object) are 64-bit aligned, so
* we can just ensure that the offset is "even". To avoid wasting space,
* we want to move non-reference 32-bit fields into gaps rather than
* creating pad words.
*
* In the worst case we will waste 4 bytes, but because objects are
* allocated on >= 64-bit boundaries, those bytes may well be wasted anyway
* (assuming this is the most-derived class).
*
* Pad words are not represented in the field table, so the field table
* itself does not change size.
*
* The number of field slots determines the size of the object, so we
* set that here too.
*
* This function feels a little more complicated than I'd like, but it
* has the property of moving the smallest possible set of fields, which
* should reduce the time required to load a class.
*
* NOTE: reference fields *must* come first, or precacheReferenceOffsets()
* will break.
*/
तो, सुपर क्लास क्षेत्रों पहले आओ (हमेशा की तरह), संदर्भ प्रकार क्षेत्रों के बाद एक भी 32-बिट क्षेत्र के बाद (यदि उपलब्ध हो, और गद्दी की आवश्यकता है क्योंकि 32-बिट संदर्भ फ़ील्ड की एक विषम संख्या) 64-बिट फ़ील्ड के बाद। नियमित 32-बिट फ़ील्ड का पालन करें। ध्यान दें कि सभी फ़ील्ड 32-बिट या 64-बिट हैं (छोटे प्राइमेटिव्स पैड किए गए हैं)। विशेष रूप से, इस समय, वीएम 4 बाइट से कम का उपयोग करके बाइट/चार/शॉर्ट/बुलियन फ़ील्ड स्टोर नहीं करता है, हालांकि यह निश्चित रूप से सिद्धांत में इसका समर्थन कर सकता है।
ध्यान दें कि यह सब 43241340 (6 फरवरी, 2013) प्रतिबद्ध के रूप में Dalvik स्रोत कोड पढ़ने पर आधारित है। चूंकि वीएम के इस पहलू को सार्वजनिक रूप से प्रलेखित नहीं किया गया है, इसलिए आपको वीएम के ऑब्जेक्ट लेआउट का एक स्थिर विवरण होने पर भरोसा नहीं करना चाहिए: यह समय के साथ बदल सकता है।
क्या आपने इसे पढ़ा/देखा है: https://sites.google.com/site/io/dalvik-vm-internals/ –
मेरे पास नहीं था, लेकिन इसमें मेरी इच्छित जानकारी नहीं है। यह एपीके और बाइटकोड के लेआउट के बारे में बात करता है, लेकिन ढेर पर वस्तुओं के बारे में नहीं। –
दलविक ज्यादातर समान दिखते हैं: 4 बाइट्स वर्ग पीआरटी, 4 बाइट लॉक, फिर डेटा: https://android.googlesource.com/platform/dalvik/+/master/vm/oo/Object.h – Chris