Memory & GC
Reveal answer and reasoning
Suppose a long-lived cache object stores a newly allocated payload. Following only stack roots and references inside the young collection area would miss that payload. CoreCLR maintains bookkeeping around relevant managed reference writes so a young collection can discover references coming from older storage. The write barrier is runtime machinery attached to reference updates; ordinary application code should use managed assignments rather than trying to maintain collector metadata itself.
A remembered reference is evidence that a young object might still be needed, not evidence that the containing cache is useful to the application forever.
The cost of a collection is also not determined only by the number of bytes allocated since the previous one. Surviving objects, scanned references, promotion and remembered locations all contribute. A program that creates many short-lived independent byte arrays can behave differently from one that continually inserts small reference-rich nodes into an old collection. Compare the same request shape and retention policy before interpreting a change in collection frequency as a regression.
A lower collection count can coexist with a larger retained heap.
In the ordinary teaching model, surviving small objects advance toward older generations when their generation participates in collection. Real CoreCLR policies have additional details, including pinning-related behavior and collection decisions based on budgets and pressure. Generation does not tell you an object's wall-clock age, business importance, or remaining lifetime. A freshly created large object can be reported as generation 2, and an object that has lived for some time can remain young if the relevant collection has not occurred.
The external experiment deliberately promotes an owner before attaching a small child. A helper marked NoInlining creates the child without returning another retained local to the caller. A forced Gen 0 collection then observes the child through the owner. These calls are bounded educational instrumentation in a new process. They are not a recipe for calling GC.Collect after each request, nor a performance benchmark.
Record the runtime and output rather than teaching one observed generation number as a language guarantee.
What a strong answer covers
- A minor collection does not reclaim the whole heap.
- Old-to-young reference writes must remain visible to a young collection.
- Removing one edge does not remove another strong owner.
Common pitfall
Treating an older object outside a minor collection as if it had already been reclaimed, or treating GC bookkeeping as application synchronization.
Follow-up questions
- What changes when the old cache loses its root before a Gen0 collection?
- Does the write barrier also make a compound cache update thread-safe?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.