On Sat, Aug 30, 2014 at 12:54:16AM +0200, Steven Bosscher wrote: > On Sat, Aug 30, 2014 at 12:23 AM, Trevor Saunders <tsaund...@mozilla.com> > wrote: > > >> Of course we should make things more explicit here and move all data > >> structures out of GC that are explicitly freed. Work in that direction is > >> welcome. The CFG is in GC memory because it indirectly refers to trees > >> (the single most reason why things are in GC space, fixable nowadays with > >> custom GC marker routines) > > > > I thought it was also because of pch? > > That used to be true, but not anymore (ever since unit-at-a-time > became the default). The CFG is only constructed after the front end > is done writing a PCH.
I was thinking about http://gcc.gnu.org/ml/gcc/2014-07/msg00298.html according to that we can't move symtab_node and friends, but maybe we can move edges and basic blocks. Trev > The CFG could be put back into arenas or pools, if custom markers are > written and could be somehow called on objects that don't live in GGC > space themselves. Right now, our marking is really just a dumb > walk-everything approach, but it should be possible to use the > hierarchy we have, starting from symtab and marking top-down - > teaching custom markers to walk the CFG of a function body but to not > mark basic blocks, edges, and whatever else makes up the CFG. > > > > I'm hoping we'll soon be at a point where everything uses the overload > > based gc scheme currently used for user gc which should hopefully make > > custom marking easier, but pch will still be a big pain, and in fact is > > by far the worst part of implementing marking functions. > > The first step really should be to simplify the marking for PCH > itself: Annotate structures for which we know they should never end up > in a PCH, and teach gengtype to just not write out marker functions > for them (just abort instead). Things that should never be seen in a > PCH: CFG basic blocks and edges, symtab nodes, GIMPLE, RTL (I think), > ... If you teach gengtype to punt on those types, transitioning to > custom marking should be far easier. > > Ciao! > Steven
