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