adding destroyable objects into Ggc

Basile Starynkevitch
Thu Oct 20 08:29:00 GMT 2011

On Wed, 19 Oct 2011 21:17:47 -0700
Lawrence Crowl <> wrote:

> Basile Starynkevitch <>
> > I would like to add destroyable objects into Ggc (the GCC garbage
> > collector, see files gcc/ggc*.[ch]).
> >
> > The main motivation is to permit C++ objects to be garbage collected
> > (I discussed that briefly in the Gcc meeting at Google in London):
> > adding destroyable object is a prerequisite for that goal.
> The C++ standard has support for garbage collection, and the general
> consensus of the committee is that object garbage collected do not
> execute their destructors.

I don't understand well this decision. Do you have URLs describing it motivations?

> Can you be specific about the use case that is driving you towards
> this solution?

PPL [Parma Polyhedra Library] data, like e.g. ppl_Constraint_t [from header
<ppl_c.h> that is, using a C API] comes to mind. If you want to share PPL stuff between
several passes, it can be very handy to add PPL data inside GTY-ed stuff. If that GTY-ed
stuff is deleted by Ggc, and if the PPL destructor (e.g. ppl_delete_Constraint in that
case) is not called, you get a memory leak. (In the MELT runtime, I have a special cases
for things like that, and they are really ad-hoc). And sharing PPL data between several
passes is useful: a first pass detect some optimization situations using PPL, and a later
pass actually does the optimizations by modifying the Gimple-s...

Very probably, if Graphite passes will add hooks for plugins [current plugins have no
good way to find what Graphite consider as induction variables inside graphite-optimized
loops, except by looking into symbol names like "graphite_IV" inside SSA names; that
would be much easier if Graphite provides a hook to tell about them, so I do hope
Graphit will add more plugin hooks!], they will benefit from it; when discussing about
Graphite people at INRIA, I got the impression that they would be happy of such features
(and conversely, plugins, in particular MELT, would benefit from more hooks from

Other usages include other finalized data, like FILE* [if a plugin need a FILE* inside
GTY-ed data to be shared by several passes, it would be handy that when the GTY-ed object
is deleted, the FILE* is fclosed] or even std::ostringstream or std::ostring-s shared
between several passes.

Maybe a compilation server might also find finalization useful.

More generally, any resource which is added, e.g. by a plugin, into a GTY-ed type and
which is used by several passes could benefit of finalizers, because from inside a plugin
you cannot easily determine when a GTY-ed data is no more used.

email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

More information about the Gcc mailing list