Scheduling Collection

We’ve already seen the JIT compiler’s role in maintaining the write barrier on behalf of the garbage collector. The compiler has another equally important role to play with regard to garbage collection scheduling in the SSCLI. Garbage collection, although it is triggered by the allocator running out of space, can occur only when all threads are at safe points in their execution and yield control to the collector. In Rotor, your thread will trigger a GC only when it asks for a collection explicitly, when it performs an object allocation, or else when it is running JIT-compiled code that polls. The last case involves generating calls from within the JIT compiler that offer to yield the thread if necessary. The helper function that the JIT inserts to implement polling is shown in Example 7-18.

Example 7-18. The JIT compiler marks good places to perform a collection (summarized from clr/src/vm/jitinterface.cpp)

void JIT_PollGC(  )
{
    Thread  *thread = GetThread(  );
    if (thread->CatchAtSafePoint(  ))   // Does someone wants this thread stopped?
    {
        CommonTripThread(  );           // Indicate we are at a GC safe point
    }
}

The JIT emits calls to this trap in places that might cause a piece of code to take a long time to complete. It uses one simple rule to place these calls: trap at all backward branches in the execution path (conditional branches, jumps with negative offsets, or leave operations). CommonTripThread indicates to the thread-scheduling machinery that it would be safe to ...

Get Shared Source CLI Essentials now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.