. Net framework of the study notes — CLR memory management \ garbage collection (a)
|
FREE Diabetes Recipes eBook! Click here to redeem. |
First, the basic principles of garbage collection analysis platform
In C #, to access a resource requires the following steps:
Call the intermediate language (IL) in the newobj instruction, for that instance of a particular type of resources allocated some memory space.
Initialize the memory from the previous step, set the initial state of resources, so that it can be used for the program. Instance of a type constructor is responsible for this initialization.
Members by access type to use of resources.
Destruction of resources in the state, the implementation of clean-up work.
Managed release of the heap memory, the step from the garbage collector solely responsible for the share of value type instances in the currently running thread of memory on the stack, the garbage collector is not responsible for the recovery of these resources, when the value type instance variable ways in which implementation of the end, their memory will be with the demise of the stack space is automatically die, does not matter recycling. For some that the type of non-managed, in its object is destroyed, it must perform some cleanup code.
After completion of initialization when the application, CLR will retain the (reserve) a contiguous address space, this space does not correspond to any of the first physical memory (backing storage) (the address is a virtual address space, so to really use it , it must be for the “submit” physical memory), the address space is the managed heap. Managed heap maintains a pointer, for the time being called NextObjPtr. The pointer identifies the next allocation of the new object position in the managed heap. At first, NextObjPtr CLR reserved address space is set to the base address.
Intermediate language instruction newObj responsible for creating new objects. When the code is run, newobj instruction will cause CLR to do the following:
All instances of the type calculated fields (and their base type for all the fields) the total number of bytes required.
The total number of bytes in front of the basis of the above plus the additional amount of objects on the number of bytes required of members: a method pointer and a SyncBlockIndex.
CLR checks whether the reserved area in the space allocation of new objects to meet the number of bytes required to submit —– If you need the physical memory. If so, the object will be assigned a place in the NextObjPtr pointer. Then, an instance of the type constructor is called (NextObjPtr will be passed to this parameter), IL instruction newobj (or the new operator) returns the allocated memory address. Newobj instruction in the address to return before the new object, NextObjPtr pointer over the area of memory in which the new object, and indicates the next new object in the managed heap address.
The following figure shows include A, B, C are three objects of the managed heap, if the redistribution of the object will be demonstrated on the NextObjPtr pointer position (immediately after C)
Heap allocation in the C language, memory, first of all need to traverse a linked list data structure, once you find a large enough block of memory, the memory block will be open to the same time, the pointer on the corresponding node list will be appropriately adjusted. But for the managed heap, the allocation of memory simply means adding a value in the pointer operation list — the practice is clearly faster than many, C language is found free space to allocate memory for objects, it creates several consecutive object, they will most likely be distributed in every corner of the address space. But in the managed heap, the object of a continuous distribution can be sure they are contiguous in memory.
For now, the managed heap to achieve the simplicity and speed is much better than the C language runtime heap. This is so because the CLR made a bold assumption — that is, the application’s address space and storage space is infinite, it is clearly impossible. Managed heap must apply some mechanism to allow this assumption. This mechanism is the garbage collector.
When the application calls the new object is created, the managed heap may not have enough address space to allocate the object. Managed heap object by the total number of bytes required to NextObjPtr up the address pointer, said detection of this situation. If the result is beyond the scope of the managed heap’s address space, then the managed heap will be considered full, requiring the garbage collector. In fact this description is too simple, in lieu of garbage collection and object is closely related to age, the need to continue to study garbage collection.
Second, the garbage collection algorithm
Garbage collection hosted by checking whether the application heap objects that are no longer used to reclaim memory. If such objects, their memory will be reclaimed. Then the garbage collector so that the application is using an object? ? Have to continue learning.
Each application has a set of root (root), a root is a storage location, which contains a reference type of memory pointer. The heap pointer or point to a managed object, or is set to null. All reference types such as global or static reference type variables are considered to be the root. In addition, a thread stack for all reference type variable local variable or parameter is also considered a root. Finally, in a way, the point of the CPU registers the object reference type is also considered a root.
When the garbage collector started, it first assumes that all objects are managed heap may be garbage collected. In other words, the garbage collector assumes that the application does not have a root object reference to the managed heap. Then the garbage collector to facilitate all the roots, construct a graph that contains all up to the object. For example, the garbage collector may locate a global variable managed object reference. The following figure shows the distribution of several objects managed heap, where objects A, C, D, F for the application of the direct reference to the root. Up to all of these objects are part of the object graph. When the object D is added to the figure, the garbage collector noted that it references the object H, so object H be added to the plan, the garbage collector in this way, a way to recursively traverse all of the available applications of objects.
Once that part is completed up to the object, the garbage collector checks the next root and traverse the referenced objects. When the garbage collector to traverse between the objects, if you find an object has been added to reach the object graph (for example, the figure above the H, D, when the check has to add up to the object graph), which stops along the path of the object identifier direction of traverse activities. Two purposes:
Garbage collector to avoid the repeated traversal of some objects can be high.
If two objects of a circular reference between, caught in an infinite loop to avoid traversal (such as reference to the figure above D H, and H and referencing D).
Once the garbage collector checked all the roots, and its up to get the object will contain all the roots from the application can access the object. Any object not in the diagram is the object of the application is not accessible, does not reach the object, and therefore can be the object of the implementation of the garbage collector. Garbage collector and then walk the managed heap linearly to find the garbage collection object contains a continuous region.
PS: CLR’s garbage collection mechanism is a bit mainstream for me, before that, I always thought that garbage collector does not reach directly to find the object, it seems that the garbage collector uses a contrarian, up to the object by finding to find unreachable objects (for this reason have to continue thinking).
If you find a larger contiguous area, the garbage collector will be the memory of some non-garbage objects move to the continuous block to compress the stack, apparently moving objects in memory will allow all of these pointers to objects become invalid . So the garbage collector must modify the application’s roots so that they point to the location of these objects are updated. In addition, if any object contains a pointer pointing to these objects, then the garbage collector is also responsible for correcting them. After the managed heap is compressed, NextObjPtr pointer will be set to point to after the last non-garbage object. The following figure shows the graph for the above garbage collection after the implementation of the managed heap.
Garbage collector can see the performance of the application is not a small effect, CLR and other measures adopted on behalf of the age to optimize the performance (after learning).
Because any non-root from the application to access the object will be collected at some point, so the application would not be possible memory leak, other applications also have been released can no longer access the object. If the object up, it will not be released; and if the object is unreachable, the application will not have access to it.
The following code demonstrates the allocation of the garbage collector is this managed object:
Code
class Program {static void Main (string [] args) {/ / ArrayList object in the managed heap, a now is a root ArrayList a = new ArrayList (); / / create 10,000 in the managed heap object for (int i = 0; i <10000; i + +) {a.Add (new Object ());// object is created on the managed heap} / / now a is a root (in the thread stack.) So a is an object of up to / /, a reference object is also up to 10,000 object Console.WriteLine (a.Count); / / return the a.Count, a will no longer be referenced by the code in the Main, / / so there is no longer a root. If another thread a.Count results are / / passed to WirteLine before the start of garbage collection, and then a reference to the 10,000 objects it will be recycled. / / Above for which the variable i though later in the code are no longer referenced, but because it is a value type, does not exist in / / the managed heap, so it is not the management of the garbage collector, it is Main After method execution will disappear automatically with the stack / / by the system recovery Console.WriteLine (“End of method”);}}
CLR has been able to use the garbage collection mechanism, there is a reason is because the managed heap always knows the actual type of an object to use its metadata information to determine an object reference to those members of other objects.
————————————————– ————————————————– ——–
On the root of the problem, discussed a lot of friends, in fact, the book does have something more detailed, only those 000 things I am more disgusted, very sorry, I posted, together with them to study:
When the JIT compiler compiles the IL code of a method, in addition to the code generated outside the local CPU, JIT compiler also creates an internal logic table. From a logical point of view, the table entry for each method identifies a method of local CPU instruction byte offset range and the range in a group containing the root of the memory address (or CPU registers), the following table describes the The memory table:
Starting byte offset byte offset at the end of the root
0×00000000 0×00000020 this, arg1, arg2, ECX, EDX
0×00000021 0×00000122 this, arg2, fs, EBX
0×00000123 0×00000145 fs
If the code is between 0×00000021 and 0×00000122 when you begin the implementation of garbage collection, then the garbage collector will know the parameters of this parameter arg2, local variables are the root fs and the EBX register, citing the managed heap object will not be considered garbage collected objects are available. In addition, the garbage collector thread can also traverse the call stack, a method by testing each of which internal table to determine the root of all calls to methods, and finally, the garbage collector to use other means to obtain stored in the global variables and reference types static reference type variable to maintain the roots.
Method in the table at offset 0×00000020 arg1 argument at the instruction is finished no longer be quoted, which means that the object referenced by arg1 after the execution of the instruction at any time can be garbage collected (assuming the application root and then there is no other reference to the object), in other words, as long as an object is no longer reachable, it is the candidate garbage collector, CLR does not guarantee that the object in a way have been alive throughout the lifetime of .
…
Sorry, the comment form is closed at this time.


Comments
No comments yet.