How Does Garbage Collection and Scoping Work in C#

How does garbage collection and scoping work in C#?

The dotnet GC engine is a mark-and-sweep engine rather than a reference-counter engine like you're used to in python. The system doesn't maintain a count of references to a variable, but rather runs a "collection" when it needs to reclaim RAM, marking all of the currently-reachable pointers, and removing all the pointers that aren't reachable (and therefore are out of scope).

You can find out more about how it works here:

http://msdn.microsoft.com/en-us/library/ee787088.aspx

The system finds "reachable" objects by starting at specific "root" locations, like global objects and objects on the stack, and traces all objects referenced by those, and all the objects referenced by those, etc., until it's built a complete tree. This is faster than it sounds.

Does the Garbage Collector clean objects created inside a { } block?

So, after some discussion and links in the comments, the answer is NO. The braces { } does not help GC at all, even when they remove variables from the scope.

With that said, the GC can clean up memory that is still in the scope, and the { } braces are pure lexical. Doing GC.Collect(); may clean up the variables even when they are in a valid context (and, of course, will not be used anymore in the code). This is not necessary in most cases, since the GC will do this automatically when needed.

How to make Garbage collector dispose a collection before it goes out of scope?

Garbage Collection in .NET is called in 3 situations :

Allocation exceeds the first generation ( gen 0 ) or large object heap threshold,
System is low on memory,
By calling GC.Collect method

Judging by your "code" I can guess that it will be called as in first situation and in this case ( because you still have a reference to that object ) I would suggest you to wrap this in to some other code block. eg :

public void A () 
{
    DoSomethingWithTheList();
    foobar();
    //more code before it goes out of scope
}

private void DoSomethingWithTheList()
{
    IList foo = bar();
    //does work on foo's items
}

If that's not possible then just try to dereference your IList object by setting it to null and then invoke GC.Collect with the highest generation as a parameter which should do the trick.

public void A ()
{
    IList foo = bar();
    //does work on foo's items
    foo = null;
    GC.Collect(2, GCCollectionMode.Forced); // force GC
    foobar();
    //more code before it goes out of scope
}

this assumes that objects in the IList foo are not referenced elsewhere

local variables in an event Handling method and garbage collection

It does get released, just not right away. Garbage collection occurs when

The system has low physical memory. This is detected by either the low memory notification from the OS or low memory as indicated by the host.

The memory that is used by allocated objects on the managed heap surpasses an acceptable threshold. This threshold is continuously adjusted as the process runs.

The GC.Collect method is called. In almost all cases, you do not have to call this method, because the garbage collector runs continuously. This method is primarily used for unique situations and testing.

This means that you can't be certain when SomeClass is getting freed unless you call for the collection yourself.

Source: https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/fundamentals

Understanding garbage collection in .NET

You are being tripped up here and drawing very wrong conclusions because you are using a debugger. You'll need to run your code the way it runs on your user's machine. Switch to the Release build first with Build + Configuration manager, change the "Active solution configuration" combo in the upper left corner to "Release". Next, go into Tools + Options, Debugging, General and untick the "Suppress JIT optimization" option.

Now run your program again and tinker with the source code. Note how the extra braces have no effect at all. And note how setting the variable to null makes no difference at all. It will always print "1". It now works the way you hope and expected it would work.

Which does leave with the task of explaining why it works so differently when you run the Debug build. That requires explaining how the garbage collector discovers local variables and how that's affected by having a debugger present.

First off, the jitter performs two important duties when it compiles the IL for a method into machine code. The first one is very visible in the debugger, you can see the machine code with the Debug + Windows + Disassembly window. The second duty is however completely invisible. It also generates a table that describes how the local variables inside the method body are used. That table has an entry for each method argument and local variable with two addresses. The address where the variable will first store an object reference. And the address of the machine code instruction where that variable is no longer used. Also whether that variable is stored on the stack frame or a cpu register.

This table is essential to the garbage collector, it needs to know where to look for object references when it performs a collection. Pretty easy to do when the reference is part of an object on the GC heap. Definitely not easy to do when the object reference is stored in a CPU register. The table says where to look.

The "no longer used" address in the table is very important. It makes the garbage collector very efficient. It can collect an object reference, even if it is used inside a method and that method hasn't finished executing yet. Which is very common, your Main() method for example will only ever stop executing just before your program terminates. Clearly you would not want any object references used inside that Main() method to live for the duration of the program, that would amount to a leak. The jitter can use the table to discover that such a local variable is no longer useful, depending on how far the program has progressed inside that Main() method before it made a call.

An almost magic method that is related to that table is GC.KeepAlive(). It is a very special method, it doesn't generate any code at all. Its only duty is to modify that table. It extends the lifetime of the local variable, preventing the reference it stores from getting garbage collected. The only time you need to use it is to stop the GC from being to over-eager with collecting a reference, that can happen in interop scenarios where a reference is passed to unmanaged code. The garbage collector cannot see such references being used by such code since it wasn't compiled by the jitter so doesn't have the table that says where to look for the reference. Passing a delegate object to an unmanaged function like EnumWindows() is the boilerplate example of when you need to use GC.KeepAlive().

So, as you can tell from your sample snippet after running it in the Release build, local variables can get collected early, before the method finished executing. Even more powerfully, an object can get collected while one of its methods runs if that method no longer refers to this. There is a problem with that, it is very awkward to debug such a method. Since you may well put the variable in the Watch window or inspect it. And it would disappear while you are debugging if a GC occurs. That would be very unpleasant, so the jitter is aware of there being a debugger attached. It then modifies the table and alters the "last used" address. And changes it from its normal value to the address of the last instruction in the method. Which keeps the variable alive as long as the method hasn't returned. Which allows you to keep watching it until the method returns.

This now also explains what you saw earlier and why you asked the question. It prints "0" because the GC.Collect call cannot collect the reference. The table says that the variable is in use past the GC.Collect() call, all the way up to the end of the method. Forced to say so by having the debugger attached and by running the Debug build.

Setting the variable to null does have an effect now because the GC will inspect the variable and will no longer see a reference. But make sure you don't fall in the trap that many C# programmers have fallen into, actually writing that code was pointless. It makes no difference whatsoever whether or not that statement is present when you run the code in the Release build. In fact, the jitter optimizer will remove that statement since it has no effect whatsoever. So be sure to not write code like that, even though it seemed to have an effect.

One final note about this topic, this is what gets programmers in trouble that write small programs to do something with an Office app. The debugger usually gets them on the Wrong Path, they want the Office program to exit on demand. The appropriate way to do that is by calling GC.Collect(). But they'll discover that it doesn't work when they debug their app, leading them into never-never land by calling Marshal.ReleaseComObject(). Manual memory management, it rarely works properly because they'll easily overlook an invisible interface reference. GC.Collect() actually works, just not when you debug the app.

NamedScope and garbage collection

TL;DR

short answer: add INotifyWhenDisposed to your View. Dispose the view. This will lead to ninject automatically disposing all stuff bound InNamedScope plus also ninject will un-reference these objects. This will lead to (eventual) garbage collection (unless you're hanging on to strong references elsewhere).

Why your implementation doesn't work

Ninject does not get informed when the view is released / get's disposed.
That's why ninject has a timer running to check whether the scope-object is still alive (alive = not garbage collected). If the scope-object is not alive anymore it disposes/releases all the objects which were held in scope.

I believe the timer is set to 30seconds by default.

Now what does this mean exactly?

if there's no memory pressure, the GC may take a long time until the scope-object is garbage collected (or he may not do it, ever)
once the scope-object is garbage collected, it may take about 30 seconds for the scoped objects to be disposed and released as well
once ninject released the scope objects, again, the GC may take a long time with collection of the object if there's no memory pressure.

Deterministically Releasing Scoped Objects

Now if you need the objects to be disposed/released immediately when the scope is released, you will need to add INotifyWhenDisposed to the scope object (also see here).
With named scopes, you'll need to add this interface to the type which is bound with DefinesNamedScope - in your case the View.

According to Ninject.Extensions.NamedScope's integration tests this will suffice: see here

Note: The only thing which is really made deterministic by this is the disposal of scoped objects.
In practice this will usually cut the time for garbage collection to occur significantly, too. However, if there's no memory pressure, again, the actual collection could still take a long time.

Implementing this should get the unit test to pass.

Note: if the root object is bound InCallScope then this solution does not work (ninject 3.2.2 / NamedScope 3.2.0). I think it's due to a bug with InCallScope but sadly i failed to report it (the bug) a few years back. I may just as well be mistaking, though.

Proof that implementing `INotifyWhenDisposed` in the root object will dispose children

public class View : INotifyWhenDisposed
{
    public View(ViewModel viewModel)
    {
        ViewModel = viewModel;
    }

    public event EventHandler Disposed;

    public ViewModel ViewModel { get; private set; }

    public bool IsDisposed { get; private set; }

    public void Dispose()
    {
        if (!this.IsDisposed)
        {
            this.IsDisposed = true;
            var handler = this.Disposed;
            if (handler != null)
            {
                handler(this, EventArgs.Empty);
            }
        }
    }
}

public class ViewModel : IDisposable
{
    public bool IsDisposed { get; private set; }

    public void Dispose()
    {
        this.IsDisposed = true;
    }
}

public class IntegrationTest
{
    private const string ScopeName = "ViewScope";

    [Fact]
    public void Foo()
    {
        var kernel = new StandardKernel();
        kernel.Bind<View>().ToSelf()
            .DefinesNamedScope(ScopeName);
        kernel.Bind<ViewModel>().ToSelf()
            .InNamedScope(ScopeName);

        var view = kernel.Get<View>();

        view.ViewModel.IsDisposed.Should().BeFalse();

        view.Dispose();

        view.ViewModel.IsDisposed.Should().BeTrue();
    }
}

It even works with `DefineDependency` and `WithCreatorAsConstructorArgument`

I don't have dotMemory.Unit but this checks whether ninject keeps a strong reference to the objects in its cache:

namespace UnitTestProject
{
    using FluentAssertions;
    using Ninject;
    using Ninject.Extensions.DependencyCreation;
    using Ninject.Extensions.NamedScope;
    using Ninject.Infrastructure.Disposal;
    using System;
    using Xunit;

    public class UnitTest1
    {
        [Fact]
        public void TestMethod()
        {
            // Arrange
            var kernel = new StandardKernel();
            const string namedScope = "namedScope";
            kernel.Bind<View>().ToSelf()
                .DefinesNamedScope(namedScope);
            kernel.DefineDependency<View, Presenter>();
            kernel.Bind<ViewModel>().ToSelf().InNamedScope(namedScope);

            Presenter presenterInstance = null;
            kernel.Bind<Presenter>().ToSelf()
                .WithCreatorAsConstructorArgument("view")
                .OnActivation(x => presenterInstance = x);

            var view = kernel.Get<View>();

            // named scope should result in presenter and view getting the same view model instance
            presenterInstance.Should().NotBeNull();
            view.ViewModel.Should().BeSameAs(presenterInstance.ViewModel);

            // disposal of named scope root should clear all strong references which ninject maintains in this scope
            view.Dispose();

            kernel.Release(view.ViewModel).Should().BeFalse();
            kernel.Release(view).Should().BeFalse();
            kernel.Release(presenterInstance).Should().BeFalse();
            kernel.Release(presenterInstance.View).Should().BeFalse();
        }
    }

    public class View : INotifyWhenDisposed
    {
        public View()
        {
        }

        public View(ViewModel viewModel)
        {
            ViewModel = viewModel;
        }

        public event EventHandler Disposed;

        public ViewModel ViewModel { get; private set; }

        public bool IsDisposed { get; private set; }

        public void Dispose()
        {
            if (!this.IsDisposed)
            {
                this.IsDisposed = true;
                var handler = this.Disposed;
                if (handler != null)
                {
                    handler(this, EventArgs.Empty);
                }
            }
        }
    }

    public class ViewModel
    {
    }

    public class Presenter
    {
        public View View { get; set; }
        public ViewModel ViewModel { get; set; }

        public Presenter(View view, ViewModel viewModel)
        {
            View = view;
            ViewModel = viewModel;
        }
    }
}

C# What is the point of the using statement?

The point of a using statement is that the object you create with the statement is implicitly disposed at the end of the block. In your second code snippet, the data reader never gets closed. It's a way to ensure that disposable resources are not held onto any longer than required and will be released even if an exception is thrown. This:

using (var obj = new SomeDisposableType())
{
    // use obj here.
}

is functionally equivalent to this:

var obj = new SomeDisposableType();

try
{
    // use obj here.
}
finally
{
    obj.Dispose();
}

You can use the same scope for multiple disposable objects like so:

using (var obj1 = new SomeDisposableType())
using (var obj2 = new SomeOtherDisposableType())
{
    // use obj1 and obj2 here.
}

You only need to nest using blocks if you need to interleave other code, e.g.

var table = new DataTable();

using (var connection = new SqlConnection("connection string here"))
using (var command = new SqlCommand("SQL query here", connection))
{
    connection.Open();

    using (var reader = command.ExecuteReader()
    {
        table.Load(reader);
    }
}

Does the .NET garbage collector perform predictive analysis of code?

The Garbage Collector relies on information ~~compiled into your assembly~~ provided by the JIT compiler that tells it what code address ranges various variables and "things" are still in use over.

As such, in your code, since you no longer use the object variables GC is free to collect them. WeakReference will not prevent this, in fact, this is the whole point of a WR, to allow you to keep a reference to an object, while not preventing it from being collected.

The case about WeakReference objects is nicely summed up in the one-line description on MSDN:

Represents a weak reference, which references an object while still allowing that object to be reclaimed by garbage collection.

The WeakReference objects are not garbage collected, so you can safely use those, but the objects they refer to had only the WR reference left, and thus were free to collect.

When executing code through the debugger, variables are artificially extended in scope to last until their scope ends, typically the end of the block they're declared in (like methods), so that you can inspect them at a breakpoint.

There's some subtle things to discover with this. Consider the following code:

using System;

namespace ConsoleApplication20
{
    public class Test
    {
        public int Value;

        ~Test()
        {
            Console.Out.WriteLine("Test collected");
        }

        public void Execute()
        {
            Console.Out.WriteLine("The value of Value: " + Value);

            GC.Collect();
            GC.WaitForPendingFinalizers();
            GC.Collect();

            Console.Out.WriteLine("Leaving Test.Execute");
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            Test t = new Test { Value = 15 };
            t.Execute();
        }
    }
}

In Release-mode, executed without a debugger attached, here's the output:


The value of Value: 15
Test collected
Leaving Test.Execute

The reason for this is that even though you're still executing inside a method associated with the Test object, at the point of asking GC to do it's thing, there is no need for any instance references to Test (no reference to this or Value), and no calls to any instance-method left to perform, so the object is safe to collect.

This can have some nasty side-effects if you're not aware of it.

Consider the following class:

public class ClassThatHoldsUnmanagedResource : IDisposable
{
    private IntPtr _HandleToSomethingUnmanaged;

    public ClassThatHoldsUnmanagedResource()
    {
        _HandleToSomethingUnmanaged = (... open file, whatever);
    }

    ~ClassThatHoldsUnmanagedResource()
    {
        Dispose(false);
    }

    public void Dispose()
    {
        Dispose(true);
    }

    protected virtual void Dispose(bool disposing)
    {
        (release unmanaged resource here);
        ... rest of dispose
    }

    public void Test()
    {
        IntPtr local = _HandleToSomethingUnmanaged;

        // DANGER!

        ... access resource through local here
    }

At this point, what if Test doesn't use any instance-data after grabbing a copy of the unmanaged handle? What if GC now runs at the point where I wrote "DANGER"? Do you see where this is going? When GC runs, it will execute the finalizer, which will yank the access to the unmanaged resource out from under Test, which is still executing.

Unmanaged resources, typically accessed through an IntPtr or similar, is opaque to the garbage collector, and it does not consider these when judging the life of an object.

In other words, that we keep a reference to the handle in a local variable is meaningless to GC, it only notices that there are no instance-references left, and thus considers the object safe to collect.

This if course assumes that there is no outside reference to the object that is still considered "alive". For instance, if the above class was used from a method like this:

public void DoSomething()
{
    ClassThatHoldsUnmanagedResource = new ClassThatHoldsUnmanagedResource();
    ClassThatHoldsUnmanagedResource.Test();
}

Then you have the exact same problem.

(of course, you probably shouldn't be using it like this, since it implements IDisposable, you should be using a using-block or calling Dispose manually.)

The correct way to write the above method is to enforce that GC won't collect our object while we still need it:

public void Test()
{
    IntPtr local = _HandleToSomethingUnmanaged;

    ... access resource through local here

    GC.KeepAlive(this); // won't be collected before this has executed
}

How Does Garbage Collection and Scoping Work in C#