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. 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
