[Mono-dev] Garbage collection for threads

Miguel de Icaza miguel at novell.com
Fri Jan 11 20:20:13 EST 2008


Hello,

> I was of the impression that mono has a separate GC thread 
> which 'periodically' and on allocation pressure, goes into a collection mode. 
> I was pointed out in the #monodev IRC that any thread could be the GC thread 
> (which kind of implied that if some thread is blocked right after it does a 
> huge allocation, those objects wont be freed) and secondly, there is no time 
> based collection, but collection happens only with allocation.

Correct, my assumption was that you had other threads running, and that
would eventually cause a GC to happen.

If you only have a single managed thread running, and that one is
blocking, there will be nothing requesting more memory which is what
would trigger the collection to happen.

> If there is no time based collection, that means once extra allocations were 
> made for whatever reason and shot up RSS (loosely using RSS for memory 
> usage), they might still be in memory long after they are discarded and the 
> RSS will still show high. This could ok for proper server apps but not for 
> desktop apps where users dont mind once in a while memory usage but after the 
> operation is done, they expect the memory to come down.

Even in that case, memory might not come down after a spike, because the
GC might not be able to return the pages to the operating system for a
few reasons: the configuration of the GC (this depends I believe on the
setting for USE_UNMAP and USE_MMAP, plus whatever heuristics at the
time) and the fragmentation of the heap at that point.

Since Boehm's GC is a conservative collector, it is unable to move
objects in a mostly unused page that could be released.    

> Can you elaborate a little more on that ? Just letting a thread run and die on 
> its own is not enough:
>   Thread thread = new Thread (new ThreadStart (Run))
>   thread.Start ();
> where Run() does a bunch of allocations. Do you mean I have to 
> manually 'terminate' the thread after it stops running ?

That is enough.



More information about the Mono-devel-list mailing list