> > Yes, that's very likely. If we'd get around to re-do the LTO option saving > > code > > we might want to forbid -g0 compile and -g link (dropping -g at link > > time as soon > > as we see a single module compiled with -g0). Then we can free some more > > stuff, at least with -g0 - though I'm not sure -g0 matters in practice. > > Don't know if it matters to care about it terribly much, but definitely > default > mozilla builds are -g0. > > I assume that now we want to be more selective about what to save for -g and > also > try to push more stuff to bypass WPA. I don't see need for all the type > merging > for stuff that is only referred from debug info. It will be fun to get this > done > however. (either by early debug info output that goes to extra section and is > distributed to ltrans same way as we distribute bodies or by some other means)
But overall 2GB of IL for Mozilla is not that bad. Ohter compilers consume easilly more. However we need to figure out where the other 4GB is going (mmap pool is obviously just part of it, probably hashtables consume good part of it, too) and do something about those 10 minutes of hashtable lookups needed to read and write out data. Problem is amount of data we produce for ltrans, that is partly because we ship debug info into units that won't output it. I guess I should look into perf and try to produce low overhead profile with backtraces so we know what hashtables are worse than others. Though we probably won't see there much surprises. Honza
