[Mono-dev] Garbage collection for threads
Miguel de Icaza
miguel at novell.com
Fri Jan 11 20:20:13 EST 2008
> 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