Shared Source CLI Essentials

Summary

We’ve seen many ways in which Rotor provides automatic memory management on behalf of managed code. The JIT compiler colludes with the code manager (for stack walking) and the metadata system to track every object reference that exists in code being managed by the execution engine. Any object instance that is in use will have at least one outstanding reference to it; because of this, instances that are no longer needed can be detected by recursively “tracing the roots,” or walking all known live references. The difference between the complete set of object references and the set of live references yields garbage, or memory that can be reclaimed.

Rotor uses a hybrid generational copying strategy for memory reclamation. When an object is allocated, the new instance is classified as either a normal object or a large object. Large objects are allocated from a special pool of memory and are managed as a simple linked list. Normal objects are allocated first within the ephemeralgeneration, a compact heap that uses a fast and simple allocation scheme. Instances with short lifecycles can come and go in this generation during the span of a single collection cycle; since the heap that backs the generation is fully reallocated on every cycle, their memory is reclaimed as old instances are overwritten. To avoid clobbering live objects, any object in the ephemeral generation that is found to be live when collection occurs has new space allocated for it in the elder generation and is ...