Re: Garbage collection

Sebastian wrote:
> Nick Roberts wrote:
[snip]
> > 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.




Chris

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