[Mono-list] Garbage collection and memory usage

Miguel de Icaza miguel at novell.com
Wed Apr 19 06:23:28 EDT 2006


> > We looked at the problem, and it boils down to the fact that Mono does
> > not have a compacting GC.
> After making some tests and googling a lot, I came to the same
> conclusion. But this only explains why the memory usage is so big, and
> keeps growing, it doesn't explain why mono "hangs" and .aspx pages are
> not processed when there is still free memory on the machine.

I could not reproduce the hang of Mono, but it did expose another
problem: I get a connection reset by peer while the large pages are
begin generated, we will investigate. 

>    And from now on, the GC is called on every 4th iteration, and
> allocated memory never drops below 160Mb and often reaches 240Mb and
> sometimes more. I surpose that calling GC more rarely is some kind of
> optimization, but it doesn't help a lot here, because we don't have
> problems with the speed of execution, but with the memory usage.

Well, the memory usage is caused because you are doing some very large
memory allocations, and that is making the GC work harder.some

If you use very large blocks of allocated memory, you can easily
fragment the heap.  Remember that the current Mono GC is not a
compacting GC, so a pattern like this would grow indefinitely:

	r = alloc (N);
	alloc (1-byte);
	r = alloc (N+1)

Even if you are dropping the "reference" to the first block a few lines
after, the heap is now fragmented due to the small allocation in the
middle.   The worst part is that you have no control over that
allocation, because it can be done behind your back (some other class
library, the runtime itself).

To keep memory usage sane, you should avoid allocating large blocks,
specially on a web application which is easily exposed to a DOS

There is a work-in-progress on a moving/compacting GC for Mono that
would solve these kinds of problems, but it wont be ready for a few more

More information about the Mono-list mailing list