Why doesn't CLR immediately release local objects that leave the scope?

[SolarianZ]

Why doesn't CLR immediately release local objects that leave the scope?

In this example, object "temp" can be released immediately.

object[] Func()
{
    List<object> temp = new List<object>(100);
    // collect...
    object[] objs = temp.ToArray(); // The scope of 'temp' ends here
    return objs;
}

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

[huoyaoyuan]

Because the GC isn't working by releasing objects. It's working by not preserving objects.

To determine an object is out of scope is a complex task. The object pointed by the variable can be assigned elsewhere. See the discussions at #1661 #4584 #97292 etc.

[SolarianZ]

Thank you. Also, do you have more information to share about this?

Because the GC isn't working by releasing objects. It's working by not preserving objects.

[huoyaoyuan]

Also, do you have more information to share about this?

Because the GC isn't working by releasing objects. It's working by not preserving objects.

The CLR GC is mark-compact GC. Every time when GC occurs, it scans for alive objects that is reference somewhere. The space occupied by dead objects become "hole" in the memory. It also has the ability to move alive objects to other place to eliminate holes.

Holes aren't reusable immediately. The allocator (new) only operates on blank segments to achieve performance. Thus, it's not useful to clear one object in a segment. The GC operates in batch by nature.

[SolarianZ]

Thus, it's not useful to clear one object in a segment.

I have learned about the GC process of the CLR from "CLR via C#." When posing this question, I have considered the issue of "hole". What if we inform the CLR to allocate objects to a dedicated memory region using specific keywords(similar to what was mentioned in #1661)? All objects in this region would be immediately erase on scope ends and not allowed to be promoted.

[huoyaoyuan]

It is effectively ref struct. ref struct is "allocated" in another way by declaring instances in local variables, and subject to lifetime rules, not allowed to be stored to any "normal" objects that's potentially alive longer.

Since it's just a new concept and fundamentally incompatible with existing types, existing code can't simply benefit from it.

[Clockwork-Muse]

As a side note: part of the complexity of the analysis is that (looking only at this method), the compiler can't actually know that temp is collectible - it's possible that ToArray() places a reference to this in the returned array!
(Or more mundanely, that somebody did something like temp.Add(temp);)

You need ownership tracking to be able to solve for this type of thing.

[CodingMadness]

As a side note: part of the complexity of the analysis is that (looking only at this method), the compiler can't actually know that temp is collectible - it's possible that ToArray() places a reference to this in the returned array! (Or more mundanely, that somebody did something like temp.Add(temp);)

You need ownership tracking to be able to solve for this type of thing.

Not sure exactly how Rust does it exactly but can you make use of the "Burrow" concept here? Sort of using that model from Rust to keep track of dangling or valid references and hence deciding when and if to release them by the GC without promoting them to higher Gens.

[alexrp]

In a word, no. Rust's borrow checker imposes restrictions that don't exist in C#, and also requires deep language/compiler support, so it is not really applicable in any useful sense.

[mangod9]

closing since the question looks to be answered