.NET generation 0 heap size

Question

Is it possible to set a minimal size of a generation 0 heap in .NET?

I have a folowing sistuation. I have a function that allocates around 20-30 MB of 1KB objects, does something with them, and terminates, leaving all the allocated objects to be GC-ed. Now, in Performance Monitor, I can see that generation 0 heap size is 5-6 MB, which is not enough to accept all the 20-30 MB of objects that I need. When I start allocating, at some point gen0 GC starts running, and since all the objects are needed it promotes them to a gen1. Next time GC starts running, these objects get promoted in gen2. So finally around 15MB of my objects end up in the gen2 heap. These are, by my logic, temporary objects that should in no way end up in the gen2 heap. I belive the problem is in the size of the gen0 heap size. But I'm not sure. I know that in Java there is a possibility to set a minimal size of the generational heaps. Is there such a way in .NET?

Answer 1

The size of the different generations is an implementation detail, and I am not aware of any ways to tune it for .NET applications. If my memory serves me correctly generation 0 and 1 shares a single segment, which is 16 MB in Win32, so if you do create a whole lot of objects, some of these will be promoted to higher generations if they are still referenced (just as you describe).

I guess the idea behind limiting the size of generation 0 is to make sure a g0 collection is cheap. If generation 0 could grow to any size, your overall performance would most likely suffer.

EDIT: I believe Jeffrey Richter's book has some details on this, so you may want to check that out.

EDIT2: Richter states (p. 502-507) that generation 0's initial budget is 256 KB and generation 1's initial budget is 2 MB. However, that is not the size of the generation. The budgets are adjusted as needed and will grow and shrink according to the application's memory usage.

Joe Duffy's Professional .NET Framework 2.0 however, states that the ephermal generations (i.e. gen 0 and 1) shares a single segment, which is usally 16 MB (p. 117). Only generation 2 is allow to grow as needed (I assume LOH is allowed to grow as needed as well, but that is not clear to me from the text).

Answer 2

Are you sure you are no longer referencing these objects? The GC is very good at tuning itself to the needs of your application and would not promote objects to Generation 2 unless you had roots for those objects somewhere.

I think if you figure out where these roots are and ensure that you really are no longer referencing these objects anywhere then the GC will start freeing the memory for those objects and never promote them to Generation 1 let alone Generation 2. Also if you do this then the GC will detect that you need Generation 0 to be larger and will increase the size of the heap on your behalf.

Answer 3

Thank you guys for your help.

Whell, the sitution is very interesting. I've never mentioned that i'm storing those 30MB of objects in an array whoose size is 100000. I'm first allocating that array and then filling it with objects. Since that array is larger than 85K that array is stored in the Large Objects Heap. It turns out that for the garbage collection to collect objects in that heap, it needs to run gen2 collection, so every time there is not enough space in the Large Objects Heap, it runs the gen2 collector, which is trashing the performance. Here is the simple example that will constantly call gen2 collection. You need to run it in debug mode (because of compiler optimizations).

static void Main(string[] args)
{
     while (true)
     {
         byte[] objects = new byte[100000];
     }
}

Does this mean that whenever I need a temporary array whose size is larger than 85K, that array will end up in the larget objects heap?

Answer 4

The Generation 0 heap is initially sized to your CPU's cache. This is so that small temporary objects don't even need to be moved to main memory.