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:

HighFrequencyHeap(MethodTables, MethodDescs, FieldDescs, and Interface Maps)

LowFrequencyHeap(EEClass and ClassLoader and its lookup tables)

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

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

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:

loader heaps (High-Frequency Heap, Low-Frequency Heap, and Stub Heap)

Handle Tables (Handle Table, Large Object Heap Handle Table)

Interface Vtable Map Manager

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:

GC Heap hosts object instances

LoaderHeaps hold together the type system

HighFrequencyHeap, contains frequently accessed artifacts:

MethodTables

MethodDescs

FieldDescs

Interface Maps

LowFrequencyHeap, contains less frequently accessed data structures:

EEClass

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:

HighFrequencyHeap initial reserve size is 32KB and its commit size is 4KB

LowFrequencyHeap and StubHeaps are initially reserved with 8KB and committed at 4KB

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.

LOH is not compacted, GC Heap(or called normal GC Heap) is compacted whenever a GC collection occurs

LOH is only collected on full GC collections