Re: PCH versus --enable-mapped-location

[Geoffrey Keating <geoffk at geoffk dot org>]

Per Bothner <per@bothner.com> writes:

> Geoff Keating wrote:
>   >> * Any source_location values handed out before the #include
> >> that restores the gch will become invalid.  They will be re-mapped
> >> to that in the pre-compiled header.  Presumably that's ok - there's
> >> no declartions or expressions in the main file at that point, or
> >> the restore would have failed.  Any declarations that are <builtin>
> >> or in the <command line> will presumably be the same either way.
> > Another way of putting this is that source_location values should be
> > in GCed memory.  I think they all are, certainly all declarations
> > and macro definitions are.
> 
> I think you're misunderstanding my concern.  The issue is when we're
> processing a .c file normally we generate source_location cookies
> for <builtin>, <command line>, and any tokens until we process the
> #include that restores the pch.  At that point we (need to) restore
> the line number saved in the pch.  Any source_location cookies
> that we've handed out up until then become invalid, because they
> refer to a line_table that has been replaced.  My point is that
> presumably it doesn't matter, since the source_location cookies
> and declarations corresponing to <builtin> and <command line>
> should match, when compared with those at pch-generation time.

The invalid cookies should no longer exist in the compiler's memory,
because they were stored in GCed memory and they were replaced by the
ones from the PCH.  After a PCH load it is as if those cookies were
never generated.

Thus, it's irrelevant whether they match, which is good, because I
don't think they necessarily would; PCH files permit you to have more
-D options on the command-line when using the PCH compared to when
generating it, so there'll be more <command line> "lines".

> The ones that don't match are any source_location cookies for
> tokens in the main file itself.  However, they should just be
> tokens for white space, comments, and the initial #include that
> triggers the pch-restoration, and there should be nothing except
> garbage that use those now-invalid source_locations.

Yes.  In fact, there won't even be garbage; the first part of loading
a PCH is that all GCed memory is marked as free.

(Thus, if you want to keep track of the name of the main file, it had
better not be in GCed memory!)

> > Custom restore code is problematic because it means doing something
> > at PCH restore time, and so it's always speed-critical.  Changing
> > two pointers is not too expensive (especially if you can arrange for
> > those pointers to be on the same page), but copying a data structure
> > (especially a large one) is not a good idea.
> 
> Then there's something I'm not getting.  The data in the line number
> has to be saved in the gch file, read in, and "patched".  This is
> true whether the data is part of the garbage collected heap, and
> so gets automatically reatored, or whether it uses special code, like
> the dependencies.

What I'm trying to say is that it's better if it's *not* "patched",
and if it does have to be changed after the PCH is loaded it's better
if those changes affect as few pages as possible.

I think you're thinking of a different kind of PCH implementation,
perhaps one where pointers are 'swizzled' when the PCH file is read.
GCC does not have one of those, because it would be slower.  Instead,
pointers are changed when the PCH file is *written*, and the PCH file
is read in without changes.

> I can see if yoyu're memory-mapping you want to do as much reading
> implicitly using mapping, rather than explicit reading.  Is that it?

No, the issue is that when you're using memory-mapping it is highly
beneficial if you avoid writing to the pages you mapped in, because
that writing forces the OS to make a private copy for this execution
of GCC, which is expensive.