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: GCC plugins & GGC & explicit gcc_free


On Sat, Aug 30, 2014 at 12:23 AM, Trevor Saunders <tsaunders@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


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