How the CLR Creates Runtime Objects

最近看到一篇文章,是介绍CLR内部是如何创建运行时对象的.感觉写的很不错,特此保存.虽然原贴针对的是.net framework1.1版本,但设计思想应该是可以延续的. 为了以后检索起来方便,做一点阅读笔记

原贴地址:英文中文

目录结构:

术语表
Domains Created by the CLR Bootstrap
System Domain
SharedDomain
DefaultDomain
LoaderHeaps
Non-LoaderHeaps

文章中用到的主要术语

Domains Created by the CLR Bootstrap:System Domain , Shared Domain, Default AppDomain
CLR Hosts: Simple host,i.e a console program; Complicated host, i.e. ASP.NET
LoaderHeaps : GC Heap hosts object instances while LoaderHeaps hold together the type system. Including:
1. HighFrequencyHeap(MethodTables, MethodDescs, FieldDescs, and Interface Maps)
2. LowFrequencyHeap(EEClass and ClassLoader and its lookup tables)
3. StubHeap(hosts stubs that facilitate code access security (CAS), COM wrapper calls, and P/Invoke.)
Type Fundamentals
GC Heap, Large Object Heap; JIT Heap; Process Heap
ObjectInstance --> TypeHandle VS
MethodTable&EEClass == Type
Interface Vtable Map and Interface Map
Method Descriptor (MethodDesc)
Virtual Dispatch
Static Variables

Domains Created by the CLR Bootstrap

Figure 1 Domains Created by the CLR Bootstrap

Before the CLR executes the first line of the managed code, it creates three application domains. Two of these are opaque from within the managed code and are not even visible to CLR hosts. They can only be created through the CLR bootstrapping process facilitated by the shim—mscoree.dll and mscorwks.dll (or mscorsvr.dll for multiprocessor systems)

System Domain and the Shared Domain, which are singletons；Default AppDomain, an instance of the AppDomain class that is the only named domain

using the AppDomain.CreateDomain with managed code or ICORRuntimeHost interface within unmanged code to create other AppDomain

System Domain

responsible for creating and initializing the SharedDomain and the default AppDomain
loads the system library mscorlib.dll into SharedDomain
keeps process-wide string literals interned implicitly or explicitly
generating process-wide interface IDs(used in creating InterfaceVtableMaps )
keeps track of all the domains in the process
implements functionality for loading and unloading the AppDomains

SharedDomain

load domain-neutral code,such as mscorlib
load Fundamental types from the System namespace during the CLR bootstrapping process
1. Object, ValueType, Array, Enum, String, and Delegate
using System.LoaderOptimizationAttribute, user code can also be loaded into SharedDomain
manages an assembly map indexed by the base address
1. acts as a lookup table for managing shared dependencies of assemblies being loaded into DefaultDomain and of other created AppDomains

DefaultDomain

an instance of AppDomain
load non-shared user code,within which application code is typically executed
cross-domain access will occur through .NET Remoting proxies
Each AppDomain has the following data structs:
1. loader heaps (High-Frequency Heap, Low-Frequency Heap, and Stub Heap)
2. Handle Tables (Handle Table, Large Object Heap Handle Table)
3. Interface Vtable Map Manager
4. Assembly Cache

LoaderHeaps

loading runtime CLR artifacts and optimization artifacts that live for the lifetime of the domain
different from the garbage collector (GC) Heap:
1. GC Heap hosts object instances
2. LoaderHeaps hold together the type system
HighFrequencyHeap, contains frequently accessed artifacts:
1. MethodTables
2. MethodDescs
3. FieldDescs
4. Interface Maps
LowFrequencyHeap, contains less frequently accessed data structures:
1. EEClass
2. ClassLoader and its lookup tables
StubHeap, contains stubs that facilitate code access security (CAS), COM wrapper calls, and P/Invoke.
Each domain has a InterfaceVtableMap (referred to here as IVMap) that is created on its own LoaderHeap during the domain initialization phase
size for each heap:
1. HighFrequencyHeap initial reserve size is 32KB and its commit size is 4KB
2. LowFrequencyHeap and StubHeaps are initially reserved with 8KB and committed at 4KB
3. The IVMap heap is reserved at 4KB and is committed at 4KB initially

Non-LoaderHeaps

Process Heap
JIT Code Heap
GC Heap (for small objects)
Large Object Heap (for objects with size 85000 or more bytes)
The just-in-time (JIT) compiler generates x86 instructions and stores them on the JIT Code Heap
GC Heap and Large Object are the garbage-collected heaps on which managed objects are instantiated.
1. LOH is not compacted, GC Heap(or called normal GC Heap) is compacted whenever a GC collection occurs
2. LOH is only collected on full GC collections