Re: GC question

Paul@iecc.com, Rubin <@iecc.com <phr-2007@nightsong.com>
30 Jul 2007 08:36:10 -0700

          From comp.compilers

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)
| List of all articles for this month |

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

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.


Post a followup to this message

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