1. About the CLR

1. What is the CLR

When the CLR (Common Language Runtime) travels in the common language, it is a "journey time" that can be used by multiple programming languages. The core capabilities of the CLR, such as memory management, assembly loading, security, exception handling, and thread synchronization, can be used by all languages that target the CLR. The CLR does not care what language developers use to program, as long as the compiler is oriented to the CLR, and all developers should use their own language that is most appropriate and familiar to program. All programming languages generate a managed module in the compilation that targets the CLR compiler. A managed module is a standard 32-bit Microsoft Windows Portable Execution Body (PE32) file, or a standard 64-bit Windows Portable pe32+ file that requires the CLR to execute.

2. The various components of the managed module

PE32 or pe32+ standard Windows PE file header, similar to "Common Object file format".

The CLR header contains information that uses this module as a managed module (which can be interpreted by the CLR and some utilities). The header contains the required CLR version, some flags, the MethodDef metadata token (token) for the managed module population method (Main method), and the location/size of the module's metadata, resources, strong names, some flags, and other less important data items

Meta data Each managed module contains a metadata table. There are two main types of tables: one type of table describes the types and members defined in the source code: Another type of table that describes source code reference types and members

The code generated by the IL (intermediate language) code compiler when compiling the source code. At run time, the CLR compiles IL to compile the cost of the CPU instruction

Use of metadata:

At compile time, the metadata eliminates the need for local C + + header and library files because all information about the type/member of the package and reference is in the IL code that is responsible for implementing the type/member. The compiler can read metadata directly from the managed module

Microsoft Visual Studio uses metadata to help you write code. That is, IntelliSense technology resolves metadata, indicating that a type provides those methods, properties, events, fields, and so on.

The CLR's code validation process uses metadata to ensure that code performs only "type-safe" operations.

Metadata allows the field of an object to be serialized into one memory, sent to another machine, and then deserialized to reconstruct the state of the object on the remote machine

Metadata allows the garbage collector to track the lifetime of an object. The garbage collector can determine the type of any object and know which fields in that object refer to other objects from the metadata.

3. Assemblies

In fact, the CLR does not work with managed modules. It works with the Assembly (assembly). An assembly is a logical grouping of one or more module/resource files. Assemblies are the smallest unit of reuse, security, and version control. The assembly is self-describing (self-describing)

4 code to execute an assembly

Managed assemblies contain both metadata and IL. In order to execute the program, it must first convert the IL to the cost of the CPU instruction. This is the responsibility of the CLR's JIT (just-in-time) compiler.

I will repeat the example of a book to illustrate how the code in an assembly is executed.

Before the main method executes, the CLR detects all the types of code references in main. This causes the CLR to assign an internal data structure that is used to manage access to the type of reference being used. For example, the main method refers to a console type, which causes the CLR to assign an internal structure. In this internal structure, each method defined by the console type has a corresponding record entry. Each record entry holds an address that can be used to find the implementation of the method. When the structure is initially initialized, the CLR sets each record entry to (pointing to) an non-documented function that is contained within the CLR. I will make this function a jitcompiler.

When main calls WriteLine for the first time, the Jitcompiler function is called. The Jitcompiler function is responsible for compiling a method IL code to compile the cost of the CPU instruction. Since IL is compiled in "instant" (just in time), this component of the CLR is usually called the jitter or JIT compiler.

When the Jitcompiler function is called, it knows which method to invoke and what type defines the method. Jitcompiler then looks for the il of the called method in the metadata that defines the assembly. Next, Jitcompiler validates the IL Code and compiles the IL code to the cost of the CPU instruction. The local CPU instructions are saved in a dynamically allocated block of memory. Jitcompiler then returns the internal data structure created by the CLR for the type, finds the record with the called Method object, modifies the original reference to Jitcompiler, and now points to the address in the memory block. Finally, the Jitcompiler function jumps to the code in the memory block.

Call WriteLine the second time. This time, because the code for WriteLine is validated and compiled, the code in the memory block is executed directly, skipping the Jitcompiler function completely.

The second call to WriteLine

5. Common Type System

In order to pass the type, code written in one programming language can communicate with code written in another language, Microsoft has specified a formal specification, the "Common Type System" (Common type System,cts), which describes the definition and behavior of the type.

The CTS specification stipulates that a type can consist of 0 or more members.

Fields (field) a data variable

Method A function

Property for the caller, the member looks like a field

Event events implement a common mechanism between objects and other related objects.

The CTS also specifies the type visibility rules and access rules for type members, such as private,family, etc.

The CTS also inherits from the type. Virtual methods, object lifetimes, and so on define the corresponding rules

Toby say one rule in the CTS: All types must eventually inherit from a predefined System.Object type. The things System.Object can do are as follows:

Compare the equality of two instances

Get the hash code for an instance

Querying the True type of an instance

Perform a shallow copy of the instance

Gets a string representation of the current state of a view instance object

6. Common Language Specification

In order to create types that are easily accessible from other programming languages, only those features that are determined by all other languages are selected from their own programming language, and Microsoft defines a common language specification (Common Language specifiaction,cls). It defines a minimum feature set in detail.

7. Meta-Data

As mentioned above, the managed PE file is composed of 4 parts: PE32 (+) header, CLR header, metadata, and IL.

Here we mainly talk about meta data.

Metadata is a binary block of data, consisting of several tables. These tables are divided into three categories: definition tables (definiton talbe), reference tables (reference table), and Manifest tables (mainfest table).

Common metadata Definition tables (when the compiler compiles the source code, anything that is defined by the code causes a record entry to be created in the table in the definition table):

Moduledef always contains a record entry that identifies the module.

Each type defined in the TypeDef module has a corresponding record entry in the definition table.

Each method defined in the MethodDef module has a corresponding record entry in the definition table.

Each field defined in the FieldDef module has a corresponding record entry in the definition table.

Each parameter defined in the ParamDef module has a corresponding record entry in the definition table.

Each property defined in the PropertyDef module has a corresponding record entry in the definition table.

Each event defined in the Eventdef module has a corresponding record entry in the definition table.

Common reference Metadata tables:

Each assembly referenced in the AssemblyRef module has a corresponding record entry in the table

Each type referenced by the ModuleRef module may be implemented by another PE module, and all of those modules have a record entry in the table

Each type referenced by a TYPEDEF module has a corresponding record entry in the table

Each member referenced by the MEMBERREF module has a corresponding record entry in the table

Inventory metadata table:

AssemblyDef If the module identifies an assembly, it contains a single record entry in the metadata table. The record entry lists the assembly name (without the path and extension), the version (Major,minor,build and revision), the language Culture (cultural), some flags, the hashing algorithm, and the publisher's public key.

FileDef each PE file and resource file that is part of the assembly has a corresponding record entry in the table.

Mainifestresourcedef each resource that is part of an assembly has a corresponding record entry in the table

Exportedtypesdef each public type that is exported from all the PE modules in the assembly has a corresponding record entry in the table.

1. About the CLR