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 -- ----------------------------------------------------------------- [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
