This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Trying to understand ggc-page vs. ggc-simple
- To: Michael Sokolov <msokolov at ivan dot Harhan dot ORG>
- Subject: Re: Trying to understand ggc-page vs. ggc-simple
- From: Richard Henderson <rth at redhat dot com>
- Date: Tue, 30 Jan 2001 02:26:47 -0800
- Cc: gcc at gcc dot gnu dot org
- References: <0101282103.AA19361@ivan.Harhan.ORG>
On Sun, Jan 28, 2001 at 01:05:50PM -0800, Michael Sokolov wrote:
> Could someone please explain to me the difference between ggc-page and
> ggc-simple and the logic behind them?
ggc-page uses something akin to vm page tables in order to track
pages allocated by the collector. We have a bit less overhead
per object that way, and it's also a bit faster to mark the
objects during collection.
ggc-simple has 3 or 4 words of overhead per object (depending on
required alignment), plus whatever overhead your malloc needs.
During collection it must look up each object in an approximately
ballanced tree.
> Back in December when I was looking into this, ggc-page required either
> mmap or valloc, otherwise ggc-simple was chosen. 4.3BSD does have valloc,
> though, which is why ggc-page got chosen.
ggc-page no longer uses valloc. We now use malloc directly for
systems that do not cannot mmap anonymous memory. This is quite
a bit more efficient than valloc, since in this scheme we waste
no more than 1 page in 16, whereas valloc tends to waste 1 in 2.
> ... but I got a rude awakening around this New Year when ggc-page,
> which configure picked by default, overflowed my 64 MB systemwide VM
> space while compiling fold-const.c in stage 2.
Try adding a call to release_pages in ggc_collect after sweep_pages.
Normally we keep hold of the "freed" pages under the assumption that
we're going to reuse them again shortly. It's possible that is not
a winning strategy for malloc, since it might badly fragment the heap.
r~