The creation location of the type instance and the structure of the hosted object on the managed Stack

1. Where to create a value-type instance:
For a value-type instance, CLR has two allocation methods at runtime: (1) if the value-type instance is used as a local variable in the Method, the instance is created on the thread stack. (2) If an instance of the value type is a member of the type, the instance is created on the GC stack as part of the instance of the reference type (the reference type is created on the GC heap or LOH. The following code demonstrates the two cases:

Public class Test1
...{
Private int I; // in the case above (2), when the Test instance is generated, the int type instance I is created on the GC stack.
Public Test1 ()
...{
In bytes B = 0; // (1), instance B of the byte type is created on the thread stack where the code is executed.
}
}

 

2. Create a reference type instance:
For referenced instances, CLR also has two allocation methods at runtime: (1) if the Size of the referenced instance is <85000 Byte, the instance is created on the Garbage Collection (GC may compress the GC heap when the CLR allocates and recycles objects). (2) if the Size of the referenced instance is greater than or equal to 85000 bytes, the instance is created on LOH (Large Object Heap) (LOH is not compressed ). The code above demonstrates the two situations:

Public class Test2
...{
Private int [] intArr;
Public Test2 ()
...{
Private Object o = new Object (); // reference o to exist on the thread stack, which points to the Object instance on the GC Stack
IntArr = new int [21250]; // meets the Size condition in (2). the instance of the int array is created on LOH.
}
}

 

3. Seven Ways of hosting objects being referenced:
The above code snippet Test2 also demonstrates two ways to reference hosted objects:
(1)IntArr is created on the GC stack along with the Test2 instance. The type (Test2) instance on the GC stack holds the reference of the hosted object (instance of the int array;
(2)Variable o of the reference type exists on the thread stack, and the local variable (o) on the thread stack holds the reference of the hosted Object (Object instance.
In fact, there are also five ways to hold references to hosted objects:
(3)Instance on the LOH stack (Same principle as 1 );
(4)Handle Table in the case of interaction with a non-hosted statement or P/Invoke );
(5)Registers, such as the this pointer and method parameters when the instance method is executed (call and callvirl commands in IL are used to process the pressure stack of function parameters from right to left and pass parameters through the stack; the fastcall command can save up to two parameters to the ECX and EDX registers respectively, and transmit parameters through registers to improve program performance; the method parameter here refers to the last fastcall condition );
(6)The Terminator queue of objects with the finalizer method;
(7)HandleTable of the type (when an object is created, the HandleTable will hold a Weak Reference ). These situations are demonstrated:

 

 

4. Managed object structure:
From this, we can see that the reference of the hosted object does not point to the starting position of the object, but has a Offset of + 4 bytes (DWord) relative to the starting position.Four bytes are called object headers.. The following is an introduction to this object header: the object header stores an index that indirectly points to the SyncTableEntry table (the syncblk number counted from 1 ). SyncTableEntry maintains a reverse weak reference so that CLR can track the ownership of SyncBlock. Weak references allow GC to recycle objects when no other strong references exist. SyncTableEntry also saves a pointer to SyncBlock, which contains useful information that is rarely used by all instances of an object. This information includes the object lock, hash encoding, any conversion layer (thunking) data and application domain indexing. Most object instances do not allocate memory for the actual SyncBlock, And the syncblk number is 0. This will change when the execution thread encounters a statement such as lock (obj) or obj. GetHashCode, as shown below:

1 Object obj = new Object ();
2 lock (obj) {/** // * Do some synchronized work here */}
3obj. GetHashCode ();

In the above Code, smallObj uses 0 as its initial syncblk number. The lock statement allows the CLR to create a syncblk entry and update the object header with the corresponding value. Because the lock keyword of C # is extended to the try-finally statement and the Monitor class is used, a Monitor object used for synchronization is created on syncblk. Heap GetHashCode calls will use the object's hash code to add syncblk. There are other domains in SyncBlock, which are used for COM interactive operations and sending delegate (delegation aling delegates) to unmanaged code, but this is irrelevant to the use of typical objects.

Followed by a syncblk numberTypeHandle handle (4 bytes), It is a bit like the virtual method table pointer in C ++, but in fact this TypeHandle points to a more complex MethodTable than the virtual method table in C ++ (this is not described here, I will discuss it later ).

Storage started after TypeHandleInstance Field. By default (that is, it is equivalent to using the StructLayoutAttribute (LayoutKind. auto), instance fields are arranged in the most effective way of memory usage, so that memory usage is more effective, the layout order of the sorted fields in the memory is not necessarily the same as the order declared by the fields in the class. This also makes it inconvenient for us to calculate the Size of the hosted object ....

<To be continued> the next article will continue to discuss how to obtain the Size of the hosted object.