Re: PCH, and more generally C++ parser performance

[Daniel Berlin <dan at cgsoftware dot com>]

>     Richard> It doesn't bring back obstack horror if you use the MMU
>     Richard> to enforce this sort of thing, which is what Zack was
>     Richard> mentioning.
> 
> Right.  But do we want to require that the OS provide that kind of
> capability?  I guess we can always fall back on what we've already
> got.

We can make ggc-page do this, since it's used on systems which are likely
to have this capability. ggc-simple could be left alone.
Does anyone know of an mmapping, or vallocing, system we support, that
can't be made to do this in a few hours?

> 
>     Richard> You guess that the memory is stable, mark it read-only,
>     Richard> and if you're wrong you get a SEGV, mark it read-write
>     Richard> again but now with knowledge that it must be rescaned.
> 
>     Richard> It is still hard though.
> 
> Right.  You have to remember not only that that memory is needed, but
> what all else is needed because it is referenced from there.  And if
> that memory *is* written, you need to decide whether or not you want
> to consider freeing the referenced memory.  If you don't want to then
> go rescan everything, you have to keep reference counts.  (Ugh.)
> 
> It's not that there's nothing good down this path -- it's just that
> deciding exactly how to do this is tricky.  I'm a little afraid we're
> putting the cart before the horse -- the last time I looked at C++
> memory usage, there looked like there were still ways to get big
> percentage eliminations in the total memory consumption.  
Absolutely.
While GC may be eating a lot of time, it's cause it has a lot of work
to do.
It's much better to reduce the amount of memory for marking to go through,
then worry about making marking quicker.

Why don't you guys (Me, i do C++ support for GDB, and so when i work on
GCC, it's removing duplicated dwarf2 info, not hacking the C++ front
end) cherry pick for a while, then start looking into difficult things.
--Dan