10: runtime relationships between types, objects, thread stacks, and managed stacks (2)

Now let's take a look at how CLR works. Assume there are two classes defined as follows:

Internal Class Employee

{

Public Int32Getyearsemployed ()

{

//...

}

Public Virtual StringGenprogressreport ()

{

//...

}

Public   Static   Employee Lookup ( String Name)

{

//...

}

}

Internal   Sealed   Class   Manager : Employee

{

Public Override StringGenprogressreport ()

{

//...

}

 }

The Windows process has been started, the CLR has been loaded to it, the managed heap has been initialized, and a thread (along with its 1 m stack space) has been created, and the thread has executed someCodeTo call the M3 method immediately, for example:

 

When the JIT compiler converts the Il code of m3 to the local CPU command, it will notice all types referenced in M3: employee, int32, manager, and string (because "Joe "), at this time, the CLR must ensure that all of these types are defined.ProgramThe collection has been loaded into the appdomain. Then, using the Assembly metadata, CLR extracts information about these types and creates some data structures to represent the type itself. Demonstrate the data structure of an object for the employee and manager types:

 

All objects on the heap contain two additional members: the type object pointer and the synchronized block index. We can see that both the manager object and the employee object have these two members. When defining a type, you can define static data fields within the type. The supported bytes for these fields are allocated in the type object itself. Each type object finally contains a method table. In the method table, each method defined in the type has a corresponding record item, which has been discussed earlier. For example, because the employee type defines three methods, getyearsemployed, getprogressreport,Loolup, so there are three record items in the employee's method table. The manager type only defines one method, so its method table has only one record item.

When the CLR determines that all types of objects required by the method have been created, and the M3 code is compiled, the thread is allowed to start executing the local code of the M3. When executing the M3 "Opening Remarks" code, the memory must be allocated from the thread heap. CLR will automatically Initialize all local variables to null or 0, for example:

 

Then m3 executes its code to construct a manager object, which creates an instance of the Manager type in the managed heap, such:

 

Like all objects, a manager object also has a type object pointer and a synchronized block index, this object also contains the bytes required for all instance data fields defined by the manager type and all instance fields required by the basic class definition. When a new object is created on the heap, CLR will automatically initialize the internal type object pointer member so that it can reference the type object corresponding to the object (in this example, it is a manager type object ). In addition, CLR initializes the synchronization block index and sets all instance fields of the object to null or 0 before calling the constructor of the type, the new operator returns the memory address of the manager object, which is saved in variable E and on the thread stack.

The code in the next line of M3 calls the static lookup method of employee. When calling a static method, CLR locates the type object corresponding to the type defined in the static method. Then, in the method table of the type object, CLR locates the record items that reference the call method, compiles the JIT method (if needed), and calls the Code Compiled by JIT. In this example, we assume that the lookup method of employee needs to query a database to find Joe, and that the database points out that Joe is a manager of the company, so internally, the lookup method constructs a new manager object on the heap, initializes it for Joe, and then returns the address of the object. This address is saved to the local variable E. The operation result is as follows:

 

Note that e no longer references the first manager object created. In fact, since there is no variable to reference this object, it is the main candidate object for future garbage collection.

The code in the next line of M3 calls the non-real-world sample method getyearsemployed of employee. When calling a non-real-world sample method, CLR will find the type object corresponding to the type of the called variable. In this example, variable e is defined as an employee (if the employee type does not define the method being called, CLR will trace back the class hierarchy and find the method in the object). Then, CLR finds the record item that references the called method in the method table of the type object, compiles the JIT method (if needed), and calls the Code Compiled by JIT, in this example, assume that the getyearsemployed method of the employee returns 5, as shown in:

 

The next line of M3 code calls the real-world sample method getprogressreport of employee. When calling a real-world sample method, CLR needs to do some additional work. First, it searches for the variables used to send the call, then follow the address to the object that sends the call. In this example, variable E points to the Joe manager object. Then, CLR checks the specified member of the internal type object of the object. This member references the actual type of the object. Then, CLR locates the record item that references the called method in the method table of the type object, compiles the method with JIT (if needed), and calls the Code Compiled by JIT, in this example, the getprogressreport Implementation of manager is called, because E references a manager object. The result of this operation is as follows:

 

Note: If the lookup method of employee finds that Joe is only an employee rather than a manager, lookup will be an internal employee object, and its type object pointer will reference the employee type object. In this way, the final execution is the implementation of the getprogressreport of the employee, rather than the implementation of the getprogressreport of the manager.

We know that an object contains a pointer pointing to the object type object (the type object contains static fields and method tables ). Both the employee and manager type objects contain type object pointer members, because the type object itself is actually an object. When creating a type object, CLR must initialize these members. When the CLR starts running in a process, it will be immediately named system. the type is used to create a special type object. The employee and manager types are "instances" of this type. Therefore, the type object pointer members of these types are initialized to the system. type object reference, of course, system. A type object itself is also an object, so it also contains a type object pointer member, which points to itself, because system. A type object is an "instance" of a type object"

Such: