Related articles |
---|
GC question phr-2007@nightsong.com (Paul Rubin) (2007-07-27) |
Re: GC question etxuwig@cbe.ericsson.se (Ulf Wiger) (2007-07-27) |
Re: GC question gene.ressler@gmail.com (Gene) (2007-07-28) |
Re: GC question bear@sonic.net (Ray Dillinger) (2007-07-28) |
Re: GC question @iecc.com <phr-2007@nightsong.com (Paul@iecc.com, Rubin) (2007-07-30) |
Re: GC question torbenm@app-2.diku.dk (2007-08-13) |
From: | Paul@iecc.com, Rubin <@iecc.com <phr-2007@nightsong.com> |
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 <bear@sonic.net> 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
comp.compilers page.
Search the
comp.compilers archives again.