This is the mail archive of the gcc@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: [RFC] type safe trees


On 24/06/2004, at 8:27 PM, Mark Mitchell wrote:

Geoff Keating wrote:

We actually did an experiment with shrinking CONST_DECLs. It wasn't very impressive; there aren't enough of them to make a difference, and they mostly live in PCH files and never get used, which is cheap.

Was this the stree experiment, or something else?

Yes, this was strees.


Also, one of the things we're thinking about is the effect on the system cache across compilations; if you have to go touch lots of pages to do GC and blow out your file system cache, then on the next compilation you're going to have to go back to disk to get the same headers (precompiled or otherwise) you just read. Have you investigated this idea at all to know whether or not there is any win to be had there?

It is indeed important to ensure that pages don't get written, or to a lesser degree read, unnecessarily. My last few patches to the C++ frontend have been directed at this. Currently most of the problems in the C++ frontend with pages being touched appear to relate to the identifier hashtable, which is not very VM-efficient, or generalised problems with end-of-file processing (in particular, template instantiation, which is what I working on last).


Yes, it would be a bad idea to design a GC system that required writing to every page on a GC collection. Fortunately ggc-page doesn't do this. PCH is irrelevant to this because by the time you are doing GC many pages will probably be on disk anyway.

It would be quite neat to have a GC system that didn't read every page, but we run GC so rarely that if you have to impose a cost on non-GC processing to make GC more efficient, I think you will lose.

If you're using the current HEAD, you should know that there's a bad performance bug in which the GC settings are wrong when --disable-checking is in effect. If you're seeing GC happen when building combine.c in a bootstrap, you either forgot --disable-checking, you're seeing this bug, or you need to go buy more RAM (even my laptop, with 256Mb of RAM, doesn't GC while building combine.c with the computed --param ggc-min-heapsize=65536).


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