On Wed, 19 Oct 2011 21:17:47 -0700 Lawrence Crowl <cr...@google.com> wrote:
> Basile Starynkevitch <bas...@starynkevitch.net> > > 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 Graphite). 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. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ 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} ***
