Re: Garbage collection (Chris Noonan)
13 Sep 2004 12:32:08 -0400

          From comp.compilers

Related articles
[12 earlier articles]
Re: Garbage collection (glen herrmannsfeldt) (2004-08-15)
Re: Garbage collection (Nick Roberts) (2004-08-23)
Re: Garbage collection (Sebastian) (2004-08-23)
Re: Garbage collection (Sebastian) (2004-08-23)
Re: Garbage collection (Nick Roberts) (2004-09-03)
Re: Garbage collection (Sebastian) (2004-09-07)
Re: Garbage collection (2004-09-13)
Re: Garbage Collection (1992-08-09)
Re: Garbage Collection (1992-08-11)
Re: Garbage Collection (1992-08-12)
Re: Garbage Collection David.Chase@Eng.Sun.COM (1992-08-13)
Re: Garbage Collection (1992-08-14)
Garbage collection (1992-11-24)
| List of all articles for this month |

From: (Chris Noonan)
Newsgroups: comp.compilers
Date: 13 Sep 2004 12:32:08 -0400
References: 04-07-085 04-08-011 04-08-032 04-08-116 04-09-013 04-09-045
Keywords: GC
Posted-Date: 13 Sep 2004 12:32:08 EDT

Sebastian wrote:
> Nick Roberts wrote:
> > I should point out that there are two kinds of problem with holes: (a)
> > running out of actual memory; (b) running out of (logical) address
> > space. I think it is (b) that is the problem with large holes.
> Hmm, unless your system has virtual memory allmost equal in size to logical
> address space for applications, then this is prpbably barely a problem. You
> can't allocate more memory than swap space + physical mem allows, so even
> significant fragmentation in case of such large objects is just
> fragmentation of address space. When size of allocatable memory approaches
> the size of logical address space compacting is no good either, as you have
> no space to copy. Without compacting you can design your app not to cause
> too much fragmentation (or at least hope that fragmentation won't be as bad
> as 2x) but with compacting you've lost. Compacting system runs out of
> memory when half of the address space is filled.
> >
> >> The main advantage of compacting collector is IMHO extremely fast
> >> allocation
> >
> > Hmmm. Well, that may be an advantage, but isn't the /main/ advantage
> > of a compacting collector the fact that it removes holes? Again, the
> > problem with these holes may be running out of address space, rather
> > than running out of actual memory, but it could be both.
> Well, IMHO the hole removal advantage is overestimated. As Hans Boehm points
> in the linked article, properly designed non compacting allocator rarely
> exhibits fragmentation worse than 2x, while compacting keeps the
> fragmentation just at or slightly above (alignment) 2x.

Interesting analysis regarding address range and paging file
memory. But you omit to say that holes between allocations consume
RAM, which is a far more valuable resource than the other two memory
types. The 2x 'fragmentation' of the copying collector does not
consume RAM.


Post a followup to this message

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