Query: Allow non static methods in top level projection

[ksmithRenweb]

Under a specific condition, disposed context's are not being released with a GC. In production it is rapidly increasing memory usage.

Memory Analysis done with Jetbrains dotMemory.

Attached working project:
ReproduceEFCoreMemoryLeakNonStaticHelperMethods.zip

Sample from attached code:

            Console.WriteLine("Take 1st snapshot!");
            Console.ReadLine();

            for(var i=0; i<10; i++)
            using (var context = new TestContextSql())
            {
                var repo = new Repository(context); // <--- The non static helper will leave 10 instances TestContextSql in memory.
                //var repo = new RepositoryStatic(context); // <--- The static helper will leave 1 instances TestContextSql in memory.

                var query = repo.GetInt();

                var list = query.ToList();
            }

            Console.WriteLine("Force GC");
            GC.Collect();
            Console.WriteLine("Take 2nd snapshot");
            Console.ReadLine();

        public IQueryable<int> GetInt()
        {
            return _context.TestEntities.Select(t => HashCode(t.DateRange1));
        }

        private int HashCode(string dateRange1)
        {
            return dateRange1.GetHashCode();
        }

Occurs in:
EF Core 2.0.1
EF Core 2.1.1

[ajcvickers]

Note for triage: I was able to reproduce this. The key part is that the query includes a call to an opaque instance method on the the repository:

public IQueryable<int> GetInt()
{
    return _context.TestEntities.Select(t => HashCode(t.DateRange1));
}

private int HashCode(string dateRange1)
{
    return dateRange1.GetHashCode();
}

Note that the repository holds a reference to the context. Removing the opaque call makes the leak go away:

public IQueryable<int> GetInt()
{
    return _context.TestEntities.Select(t => t.DateRange1.Length);
}

[ksmithRenweb]

Morning,

Last Friday I tried to keep to just the bare bones so I did not run on and on. I'll add a bit more detail today.

I took a memory dump of a web api process running at GB's of memory when it should have been under 500 MB like all the others. I found that it was holding onto 50k context objects each with 300 KB of memory reserved.

After a review of how we are handling context disposal and knowing that every other web api was not having this issue. I reviewed commits till i found the culprit.

A developer wrote a couple repository helper methods, that are called during the IQueryable. Best practices say they should have been static if they could have been and they could have. The helper methods are more complex than the GetHashCode I used in the example here.

It seems that when EF Core compiles the IQueryable it stores any such methods in a MemoryCache. Probably a really good idea for performance. But. Disposing of the context does not release those methods from the MemoryCache. Which is the Memory Leak!

The reason that making the helper methods static negates this memory leak is due to how static works in the language. Without static, EFCore is keeping a reference to each instance of the repository and it's helper method, which happened to hold a reference to the context. Thereby not allowing GC to pick it up. With static, EFCore only keeps 1 reference to the "static" helper method. So though its still arguably a memory leak, it is very minor.

I hope this helps understanding the issue.

[ajcvickers]

@ksmithRenweb Sorry, I should have said that we know what the issue is. Deciding what to do about it is a different matter--it plays into #12795 because behavior is a consequence of how we evaluate the opaque method call on the client. We're considering changing some of this in 3.0.

[ajcvickers]

Outcomes from triage discussion: detect when something problematic is being captured and then warn and don't cache (since cache entry will never be used anyway).

[ajcvickers]

For triage: discuss workarounds.

[ajcvickers]

We investigated workarounds here, but the options are limited. In general, the workarounds are all about preventing state being captured where that state causes problems. In the specific cases here, that state is the context instance. For this, three things to try are:

• Make sure the context instance (or whatever other state exists that is causing issues) isn't referenced from the method call, and hence won't be captured in the closure.
• In some cases, this may be possible by replacing instance access with static access, like in the example above, such that the implicit reference to the context is not captured in the closure.
• Another approach that works for the DbContext specifically is to make the method call actually be on the DbContext type. This pattern is detected and parameterized. For example, in the code above if the call is made directly on the context instead of through the repository, then it would be detected and parameterized.