Re: GC question, Rubin < <>
30 Jul 2007 08:36:10 -0700

          From comp.compilers

Related articles
GC question (Paul Rubin) (2007-07-27)
Re: GC question (Ulf Wiger) (2007-07-27)
Re: GC question (Gene) (2007-07-28)
Re: GC question (Ray Dillinger) (2007-07-28)
Re: GC question < (, Rubin) (2007-07-30)
Re: GC question (2007-08-13)
| List of all articles for this month |

From:, Rubin < <>
Newsgroups: comp.compilers,comp.lang.functional
Date: 30 Jul 2007 08:36:10 -0700
Organization: Nightsong/Fort GNOX
References: 07-07-098 07-07-105
Keywords: GC, performance
Posted-Date: 30 Jul 2007 23:18:36 EDT

Ray Dillinger <> writes:
> Now, here's the harsh truth that applies to all conventional
> Garbage Collectors. As your live data grows in size, the
> smallest achievable product of those two fractions will tend
> to increase. The smaller the fraction of the memory space
> that your system allows to be floating garbage, the larger
> the fraction of CPU power your GC will use. The smaller the
> fraction of CPU power you devote to it, the greater will be
> the fraction of your memory arena devoted to holding floating
> garbage. ...

Thanks for this detailed reply, which I'm still trying to digest.

> It is much cheaper in the long run to double the size of the memory
> arena each time you run out of space - then you get costs linear
> with the size of your final memory arena.

Right, I think there's no way around this. I had thought of
generation scavenging in terms of doubling the time between
collections at each generational level, avoiding the O(N**2) time
complexity, but that has the same effect on memory consumption as
doubling the arena size on running out of space.

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.