ObjectInstance

We'll use the term ObjectInstance for the data structure located at the address pointed to by the object reference.

Before an object instance is created, the CLR looks up the loaded types, loads the type if not found, obtains the MethodTable address, creates the object instance, and populates the object instance with the TypeHandle value. The JIT compiler-generated code uses TypeHandle to locate the MethodTable for method dispatching. The CLR uses TypeHandle whenever it has to backtrack to the loaded type through MethodTable.

A typical object instance layout is as follows.

• An index (a 1-based syncblk number, DWORD) into a SyncTableEntry table. For most object instances, there will be no storage allocated for the actual SyncBlock and the syncblk number will be zero. This will change when the execution thread hits statements like lock(obj) or obj.GetHashCode.
• The TypeHandle that points to the MethodTable of the corresponding type.
• A variable list of instance fields. The lexical sequence of member variables in the source code is not maintained in memory by default.
• String literals

An object can be referenced from stack-based local variables, handle tables in the interop or P/Invoke scenarios, from registers (the this pointer and method arguments while executing a method), or from the finalizer queue for objects having finalizer methods. The OBJECTREF does not point to the beginning of the Object Instance but at a DWORD offset (4 bytes).

ObjSize (SOS command) will not include the memory taken up by the syncblk infrastructure. Also, in the .NET Framework 1.1, the CLR is not aware of the memory taken up by any unmanaged resources like GDI objects, COM objects, file handles, and so on.

Again all the notes above are taken from the article JIT and Run: Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects by Hanu Kommalapati and Tom Christian.