Section 14th: Thread hijacking

The garbage collection period algorithm is discussed earlier in this chapter. However, these discussions have a big premise: only one thread is running, and in the real world, multiple threads are frequently accessing the managed heap at the same time, or at least multiple threads concurrently manipulating the objects allocated in the managed heap. When one thread throws a garbage collection, other threads absolutely cannot access any other pairs (including references on their own thread stacks), because the garbage collector may move the object and change its memory address.

Therefore, when the garbage collector wants to turn on garbage collection, all threads that are executing managed code must hang. The CLR uses several different mechanisms to ensure a secure suspend thread, so that the garbage collection period can execute normally, and there are many mechanisms to keep threads running as much as possible and to minimize overhead. This section does not discuss these large amounts of detail, and Microsoft has done a lot of work to reduce the cost of the garbage collection period. Over time, Microsoft will continue to improve these mechanisms to ensure efficient garbage collection.

When the CLR wants to start a garbage collection, it immediately suspends all threads that are executing managed code. The CLR then examines each thread's instruction pointer to determine where the thread is executing. The instruction pointer address is then compared with the JIT compiler-generated table to determine what code the thread is executing.

If the thread's instruction pointer is exactly a marked offset in a table, it says that the thread has arrived at a safe point. Threads can be safely suspended at secure points until the end of garbage collection. If the thread's instruction pointer is no longer an offset from the internal method table tag, it indicates that the thread is not in a secure point and the CLR cannot perform garbage collection. In this case, the CLR will hijack the thread. In other words, it modifies the line stacks so that the return address points to a special function of the CLR's internal implementation. Then, the thread resumes running. When the currently executing method returns, a special function begins execution, which suspends the thread.

However, a thread can sometimes be long and cannot be returned from the current method. Therefore, when the thread resumes execution, the CLR attempts to hijack the thread with an event of approximately 250 milliseconds. After this time, the CLR suspends the thread again and checks its instruction pointer, and if the thread arrives at a secure point, the garbage collector can execute it. However, if the thread does not arrive at a security point, the CLR checks to see if another method was called. If it is, the CLR modifies the line stacks again so that the most recent method executes after it returns to the hijacked thread. The CLR then resumes the thread for the next hijacking.

After all threads arrive at a secure point or are hijacked, the garbage collection period can begin. After the garbage collection is complete, all threads are restored and the application continues to run. The hijacked thread returns their own method.

There is one more place to pay attention to this algorithm. When the CLR wants to start a garbage collection, it suspends the thread that is executing all managed code. However, threads that are executing unmanaged code are not suspended. So the garbage collection period is allowed to start after the thread that is executing the managed code arrives at a security point or is hijacked. Threads that are executing unmanaged code are allowed to run because any object they are using (where in memory) should be fixed, and if the thread that is executing unmanaged code returns managed code, the thread is immediately hung up until the garbage collection is complete.

In practical applications, most of the CLR suspends threads by hijacking a thread, rather than judging whether a security point is reached based on the table generated by the JIT compiler. This is because the JIT-generated table requires a lot of memory and increases the working set, which can severely impact performance. Therefore, if the method contains loops and no other methods are called in the Loop, the JIT compiler-generated table contains information about the methods. Conversely, if another method is called in the loop, or there is no loop at all, in the JIT compiler-generated table, it does not contain much information about the method, and the CLR mainly suspends the thread by hijacking.

Section 14th: Thread hijacking