-1

In C#, assume you run many threads doing a lot of computations with a lot of objects and RAM. In the end, all threads are done. Then you run GC.Collect(). You just don't stop the process.

Except if you stored references to some objects in static variables, I expect that, in the end, the RAM being used is back to 0, except loaded DLL or things that do use a lot of RAM (a lot means several GB).

Is it true?

Are there possible remaining big RAM usage we might not be aware of? (excluding memory leaks caused by wrong code)

Benoit Sanchez
  • 681
  • 6
  • 21
  • 1
    This feels like a XY Problem - https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem . _Why_ do you care? What is your actual, real, underlying problem that you are trying to solve? – mjwills May 16 '18 at 11:32
  • 1
    Also, you have a hypothesis - what happened when you **tested** it? – mjwills May 16 '18 at 11:33
  • "Except if you stored references to some objects in static variables" Static variables are variables in memory like every function local one. Variablescope is only a compile time convention like strong typisation and class accessors to avoid a number of possible bugs. Anything assigned to a static variable has a unbroken chain of strong references to a Application root, and is this not eligible for collection. But I agreee it does sound a bit like a XY Problem. We generally do not do these kind of memory-micro-optimisaitons. – Christopher May 16 '18 at 11:37

1 Answers1

0

Are there possible remaining big RAM usage we might not be aware of?

Yes. Actually GC.Collect() does not collect all the allocated memory. It only collects generations 0,1,2 that are all "small" objects.

Note: it's not even clear as to whether GC.Collect() always causes a full garbage collection of generations 0,1 and 2. People have varying strategies to deal with it but I don't want to elaborate on this since I don't have the final answer and it seems to depend on .NET versions.

There is another heap Large Object Heap, sometimes called the 4th heap (or even 3rd generation which is not a good name) where all objects with size >85000 are allocated.

This heap has a completely different functioning. Read for example:

The Large Object Heap appears to be reserved by the process (by Windows) while it is actually full of "holes" that can be used by new (large) objects and are seen as free by the C# memory manager.

The Large Object Heap cannot be compacted manually before .NET 4.5.1. It only happens when the CLR needs/wants it.

Whether the CLR compacts the LOH often or not depends on what garbage collector you use. Typically the server GC, used by default in ASP.NET, does not compact the LOH. Actually this is true for .NET 4.5 but might have evolved in next versions. The strategies to manage the LOH tend to evolve quite a bit in .NET versions. Not every detail that were explained once remain true.

As far as I know this might be the main cause of observing several GBs of remaining RAM (that are not memory leaks). Most often this is not a problem. You'll find a lot more here: When is memory, allocated by .NET process, released back to Windows

Benoit Sanchez
  • 681
  • 6
  • 21