Type Fundamentals

The CLR version of a type declaration consists of a MethodTable and an EEClass. If you use the SOS command !Name2EE, you will get both addresses of EEClass and MethodTable for a type. Except the !Name2EE command, you can get both addresses using the !DumpObj command.

EEClass comes to life before the MethodTable is created. In fact, EEClass and MethodTable are logically one data structure (together they represent a single type), and were split based on frequency of use. Fields that get used a lot are in MethodTable, while fields that get used infrequently are in EEClass. Thus information (like names, fields, and offsets) needed to JIT compile functions end up in EEClass, however info needed at run time (like vtable slots and GC information) are in MethodTable.

MethodTable and EEClass are typically allocated on the domain-specific loader heaps. Byte[] is a special case; the MethodTable and the EEClass are allocated on the loader heaps of the SharedDomain.

EEClass

There will be one EEClass for each type loaded into an AppDomain. This includes interface, class, abstract class, array, and struct. The CLR class loader creates EEClass from the metadata before MethodTable is laid out.

Each EEClass is a node of a tree tracked by the execution engine. CLR uses this tree to navigate through the EEClass structures for purposes including class loading, MethodTable layout, type verification, and type casting.

EEClass has a circular reference to MethodTable. EEClass is allocated on the LowFrequencyHeap of the AppDomain so that the operating system can better perform page management of memory, thereby reducing the working set.

EEClass has three fields to manage the node relationships between loaded types: ParentClass, SiblingChain, and ChildrenChain.

MethodTable

There will be one MethodTable for each declared type and all the object instances of the same type will point to the same MethodTable. This will contain information about the kind of type (interface, abstract class, concrete class, COM Wrapper, and proxy), the number of interfaces implemented, the interface map for method dispatch, the number of slots in the method table, and a table of slots that point to the implementations.

A pointer to the MethodTable can be acquired even in managed code through the Type.RuntimeTypeHandle property. TypeHandle, which is contained in the ObjectInstance, points to an offset from the beginning of the MethodTable. This offset is 12 bytes by default and contains GC information.

MethodTable is allocated on the HighFrequencyHeap of the AppDomain. One important data structure MethodTable points to is EEClass.

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. I do understand the meaning of "loading a type" in CLR much better after reading the article.