|GC question firstname.lastname@example.org (Paul Rubin) (2007-07-27)|
|Re: GC question email@example.com (Ulf Wiger) (2007-07-27)|
|Re: GC question firstname.lastname@example.org (Gene) (2007-07-28)|
|Re: GC question email@example.com (Ray Dillinger) (2007-07-28)|
|Re: GC question @iecc.com <firstname.lastname@example.org (Paul@iecc.com, Rubin) (2007-07-30)|
|Re: GC question email@example.com (2007-08-13)|
|From:||Paul@iecc.com, Rubin <@iecc.com <firstname.lastname@example.org>|
|Date:||30 Jul 2007 08:36:10 -0700|
|Posted-Date:||30 Jul 2007 23:18:36 EDT|
Ray Dillinger <email@example.com> 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.
Return to the
Search the comp.compilers archives again.