This is the mail archive of the 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

Geoff Keating <> writes:

> Ian Lance Taylor <> 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

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.


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