Re: [PATCH]: Pool allocator

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Fri, 20 Dec 2002 02:49:52 -0800
> From: Richard Henderson <rth@redhat.com>
> Cc: Daniel Berlin <dberlin@dberlin.org>, gcc-patches@gcc.gnu.org

> On Wed, Dec 18, 2002 at 02:59:27PM -0800, Geoff Keating wrote:
> > If you plan to do much work on memory management, you really want to
> > look at the pch-branch.  PCH puts extra requirements on memory
> > allocators.
> 
> Briefly, like what?

Hmmm.  I should really write documentation for those routines.

Basically, an allocator has to be able to efficiently restore a
previously saved memory image.  The key routine that it must implement
is `ggc_pch_read'; despite the name, this doesn't actually read any
objects (this is done by common code), but it does set up the
allocator's data structures so that the allocator can recognize the
just-read memory (for ggc_set_mark, for instance).  There are other
routines that need to be implemented to write out any data needed by
ggc_pch_read, and to layout the memory that'll be read.

> Yesterday and today I've been playing with a re-organization
> of ggc-page.c such that we no longer segregate object sizes
> into different pages.  
> 
> I've only had a chance to do limited performace testing on 
> the thing so far (which is why I havn't posted it).  Despite
> the theoretical higher overhead of the metadata, core sizes
> do appear to be smaller.  Runtime performance is a little 
> worse still; I'm hoping that's fixable.

I'd expect that most of the cost in runtime performance would be in
ggc_set_mark...

-- 
- Geoffrey Keating <geoffk@geoffk.org>