Re: Time to heat up the new module discussion



On 07/14/06 Jamie McCracken wrote:
> Every compacting GC automatically doubles memory use - you have two 
> managed heaps ergo twice the RAM required. If you copy MS and go for a 
> three generation one then you risk trebling memory use over using a 
> non-compacting one.

This info is completely wrong.
First, it is a particular kind of compacting GC that requires the
double of the used memoryr: copying GC. Nobody uses that design for
production. There are many alternative designs neither of which requires
much more memory than the amount used, mostly the same amount wasted for
fragmentation and bookeeping in malloc implementations.
Usually a copying GC design is used only for the young generations
in a generational GC design. The current mono code uses copying-like GC
for the old generation, but this is only a temporary implementation
to focus first on the support the runtime needs for a moving GC (it is
only 200 lines of code and reuses the young generation GC code, so it
helps with debugging). Later it will be implemented using mark-compact,
which doesn't require any additional memory.
Similarly, it's completely false that a three generation GC requires
three times the memory, there is a lack of basic understanding of
garbage collectors here.

> In the end you have to choose between fast garbage collection (and up to 
> 6x memory use) or slow garbage collection with more modest RAM 
> requirements - there is no perfectly efficient *and* fast GC out there 
> and they have been searching for it for the last 50 years.

There is no "perfectly efficient *and* fast" anything in computing that
is not for extremely trivial issues, so not sure what value that remark has.
There are several papers that show that GCs can be faster than
explicit memory management with comparable memory overhead.

lupus

-- 
-----------------------------------------------------------------
lupus debian org                                     debian/rules
lupus ximian com                             Monkeys do it better



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]