You sometimes see pieces of code which set local variables to null with the aim of releasing instances early. In debug builds, local variable lifetimes are extended to the end of the method, but for release builds I think you’d expect the jit compiler to calculate the liveness information (in most situations) to allow resources to be freed early.

Given a class Test1, I want to have a quick look at the liveness information that is calculated for the method:

Note that in the above C# code, I needed to keep going until five local variables to make sure that there is a need to spill some locals on to the stack. This is the disassembled code for the method which we can cross-reference with the pointer tracking information from gcinfo.

We have now allocated the object in the local variable target. This is returned in eax, which we place into the [ebp-10h] spill. The pointer tracking, above, notes that the spill contains a tracked value after this instruction.

The local variable target2 is held in esi. This is live for the next 8 call instructions according to the pointer map from the gcinfo. Information such as call [ EDI ESI ] argMask=00is showing that EDI and ESI contain live pointers at the point of the calls.

The pointer tracking for [ebp-10h], the spill holding target, is no longer live according to the pointer tracking information. [ebp-10h] was live from 0016..0072. The local variable target is now dead.

From the liveness information, we can see that locations holding the various locals are only tracked for some of the method scope. Hence there is no need to set such locals to null as the liveness information means that the values they hold are not going to be traced by the garbage collector anyway.