1
void method () 
{
   Type obj = new Type () ;
}

maybe i misunderstand something, but when function returns and stack is unwound, 'obj' somehow must be deleted from the root set. how does this mechanism work? I already searched here and googled it, but found nothing to clarify my question.

Volodymyr Boiko
  • 1,533
  • 15
  • 29
  • The .NET GC is a mark-and-sweep collector. If an object is not found in the mark phase, it's sweeped :) Note that `obj` was never part of the root set in the first place, it was referenced from the stack crawling phase. I can't go into details because as-is your question is quite broad, maybe try to explain what *precisely* you don't understand. – Lucas Trzesniewski Feb 18 '17 at 12:57
  • @LucasTrzesniewski, when function is called in a thread, garbage collector must be noticed about references that are created at the call stack. and when function exits, garbage collector must not check that references anymore, yes.? if so, then how is it actually implemented.? – Volodymyr Boiko Feb 18 '17 at 13:13

2 Answers2

3

There is no "subtraction", that would make calling a method entirely too expensive. A primary role here is played by the just-in-time compiler. It does not just translate MSIL to machine code, it also generates a table that describes how objects are used by the method. That table contains the addresses of the code locations where the object is used as well as where it is stored.

Note how the stack is an abstraction, the far more common place where an object reference is stored is in a processor register. The GC needs to know what register is used to properly track object usage. And the stack frame offset if it does get spilled to the stack.

When the garbage collector gets going then it walks the stack, traversing the stack frames of the active methods. And uses the table associated with each method to find the object references back. With the big advantage that nothing special needs to be done when a method completes, the stack frame simply is not there anymore. The table also makes garbage collection very efficient, an object can be collected even when the method has not yet finished executing. Matters a lot for, say, your Main() method, you would not want any object you use in that method to leak for the lifetime of the app. It makes the fixed statement very cheap, the table simply has a bit that says that the object should not be moved.

The existence of that table is the distinction between managed and unmanaged code. More about that table in this answer.

Community
  • 1
  • 1
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • is it documented somewhere.? – Volodymyr Boiko Feb 18 '17 at 13:47
  • Not that I know of, you'd have to read CLR source code. I suspect that Jeffrey Richter would mention it in his books, been too long since I read one. CoreCLR on GitHub is a good way to see stuff like this. Or SO of course :) – Hans Passant Feb 18 '17 at 13:53
  • 2
    @GreenTree it's documented a tiny bit in the [BOTR](https://github.com/dotnet/coreclr/blob/master/Documentation/botr/README.md), more precisely [here](https://github.com/dotnet/coreclr/blob/master/Documentation/botr/ryujit-overview.md#gc-info). You may be interested in the [GC chapter](https://github.com/dotnet/coreclr/blob/master/Documentation/botr/garbage-collection.md) as well. – Lucas Trzesniewski Feb 18 '17 at 14:01
0

See this article here. http://www.c-sharpcorner.com/uploadfile/riteshratna/garbage-collection-memory-management-in-net/

Check out the section on managed heap through application roots. This list of roots is available to the garbage collector to determine which object can be collected.

Fran
  • 6,440
  • 1
  • 23
  • 35
  • Please don't link to external sites unless the link is to support content you've already put in your question. External links can disappear rendering your answer void. – Enigmativity Feb 18 '17 at 13:43