Re: Time to heat up the new module discussion
- From: Paolo Molaro <lupus debian org>
- To: desktop-devel-list gnome org
- Subject: Re: Time to heat up the new module discussion
- Date: Mon, 17 Jul 2006 16:37:21 +0200
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]