Type Basics of the first read CLR Via C # (2) Relationship between program running

 

In this blog post, it may be difficult to say something. I was prepared to update it the day before yesterday, but I have been unable to find a proper statement for repeated consideration, I may not understand it very well. Therefore, in this blog post, I hope the majority of users will point out something wrong and correct it. Let's make common progress. Next, let's start.

When we write a program module and submit it to PM for verification, we will run it first to find bugs for testing and correct them. But how does CLR load programs when we run the debugging module?

When the CLR starts to load a process, there will be many threads in the process. When a thread is created, the CLR will automatically allocate 1 MB of stack space, store the parameters required by the current method and the local variables defined in the method, and pass the parameters of the next method. Before JIT compiles this method as a local CPU command, CLR must ensure that all the Assembly defined in this method is loaded into the current APPDomain, perform an initialization operation on all the local variables in this method (initialize the variables to null or 0). Then, CLR uses the Assembly metadata to extract type information. Speaking of this, we will introduce some knowledge. How does CLR know the methods and attributes of these types of objects? During compilation, none of the types correspond to three tables. In the next section, we will only introduce the metadata definition table, because the length is too long.

Metadata definition table:

When the compiler compiles the source code, a corresponding record will be inserted in the Table in any of the Code. This table contains:

1. ModuleDef: contains the module's identification records, including the file name and extension, and an ID generated by the GUID;

2. TypeDef: contains any defined type name, base class, identifier (public \ private) in the module, and indexes pointing to MethodDef, FieldDef, ParamDef, PropertyDef, and EventDef;

3. MethodDef: contains the name, identifier (private public), and index pointing to ParamDef defined in the module;

4. FieldDef: contains the name, identifier (public \ private), and type of each field defined in the module;

5. ParamDef: contains the name, identifier (in \ out \ ref), and type of each parameter defined in the module;

6. PropertyDef: contains the name, identifier, and type of each attribute defined in the module;

7. EventDef: contains the name and ID of each time period defined in the module.

This is an approximate component of the metadata definition table. There are two other tables, which will not be described here.

In my opinion, CLR finds the metadata of all the assembly required by the object reference in this table, loads it, pushes it into the stack space, and executes it. So what is the specific execution? Because I am afraid that my understanding is incorrect, I do not dare to paste the pictures I have drawn into the blog, so I am afraid that they will be misleading. So I will write my own opinions in the original book, sorry! First, we assume there are two classes:

 

Www.2cto.com

Internal class Employee

 

{

 

Public Int32 GetYearsEmploye ()

 

{

 

Return-1;

 

}

 

Public virtual String GenProcessReport ()

 

{

 

Return string. Empty;

 

}

 

 

 

Public static Employee LockUp (String name)

 

{

 

Return null;

 

}

 

}

 

 

 

Internal class Manager: Employee

 

{

 

Public override string GenProcessReport ()

 

{

 

Return base. GenProcessReport ();

 

}

 

}

 

 

Assume that after the Windows process is started, the CLR has loaded the required assembly metadata, initialized the stack, and allocated 1 MB of stack space to the current thread.

We can see that the thread Stack has a shadow part. We can understand that this thread has executed some code and is about to execute the M3 method immediately. According to the operating mechanism of CLR, JIT must first compile the cost-effective CPU commands of the M3 method. At the same time, CLR must ensure that all types of the M3 method have been loaded in the APPDomain. Then, the metadata definition table is used to find all the required information of M3, and a data table is built on the heap to represent the objects of the Employee and Manager types,

At this time, after the CLR determines that all types required by the method have been created, and the code of the M3 method is compiled, the code can be executed. During code execution, CLR will automatically initialize the members of the object and initialize the field of the object instance to null or 0, will execute the constructor we wrote in the Code (in the previous article, I will show you how to create an object instance)

Indicates that the constructor of Employee has been called and an instance has been created in the heap. The type object pointer returns the object memory address.

Then, the code needs to execute a static method as "Lookup". When this method is executed, the CLR will locate the type of the static method, then compile through JIT (if JIT has been compiled, you do not need to compile it again ). The Lockup method will create a new Manager object internally, return the address of the object, and save it by e local variable.

In this case, the address of the object stored by e is no longer the address of the previous Manager object. At this time, the address is the address of the Employee object, and the previous Manager object is no longer referenced by an object, wait for GC to be recycled, and it becomes the main object for GC collection. In the execution to year = e. getYearsEmployed (); when using the method, CLR also needs to find the record items of this method (I think in the metadata definition table) and then JIT compilation (if JIT has been compiled, it does not need to be compiled again) and return the data to the year variable,

In the last step, when we run to e. when GetProgressReport () is used, CLR searches for the corresponding object based on the method. At this time, the e variable points to the Manager object because the GetProgressReport () in the Employee object () the final implementation of the virtual method is in the Manager class. CLR also needs to find the record items of this method (I think it is in the metadata definition table) and then JIT compilation (if JIT has been compiled, it does not need to be compiled again ).

 

At this point, the relationship between the running of the program is my opinion. If there are any errors, please correct them. Thank you!

 

Author: LouisLee