This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix zone garbage collector to support PCH


> X-Original-To: geoffk@foam.wonderslug.com
> From: Ian Lance Taylor <ian@wasabisystems.com>
> Cc: dberlin@dberlin.org, gcc-patches@gcc.gnu.org
> Date: 04 Mar 2004 07:13:39 -0500
> X-OriginalArrivalTime: 04 Mar 2004 12:02:30.0531 (UTC) FILETIME=[91E65530:01C401E0]
> 
> Geoff Keating <geoffk@geoffk.org> writes:
> 
> > Ian Lance Taylor <ian@wasabisystems.com> writes:
> > 
> > > I don't know why ggc-page.c bothers to page align the file pointer.
> > > The file is just being used for fread() and fwrite() of sizes which
> > > appear to normally be less than a page.  I can't see why aligning the
> > > file pointer provides any benefit, and it obviously makes the
> > > resulting PCH file a bit larger.  However, I didn't try to change
> > > that.
> > 
> > I believe it's to make mmap work better.  It certainly makes it more
> > efficient, I'm not sure if there aren't platforms where mmap doesn't
> > work at all if you don't do this.
> 
> The code in question, in ggc_pch_write_object() and
> ggc_pch_total_size() in ggc-page.c, is page aligning in the middle of
> the area of the file which is being mapped in.  gt_pch_save() ensures
> that the file offset starts on a page boundary, which is required by
> mmap().  I'm not aware of any mmap() implementation which requires
> that the total length be a multiple of the page size, but if we want
> to be cautious that too could, and probably should, be handled by
> gt_pch_save().
> 
> Right now ggc-page.c is page aligning between each set of pages
> allocated for a particular size.  Thinking about it, I see that some
> alignment is required here, to ensure that the next set of objects
> starts at an appropriate alignment.  But I don't see why page
> alignment is required between sets of pages.

Oh, *that* page-alignment.  That's to support lookup_page_table_entry,
called via ggc_set_mark.  PCH objects never get freed, but
ggc_set_mark must still work to avoid recursion when the objects are
being walked.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]