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: adding destroyable objects into Ggc


On Fri, 21 Oct 2011 10:43:29 +0200
Richard Guenther <richard.guenther@gmail.com> wrote:
> So there is no inherent limitation with the GGC machinery.

There are at least some annoyances:

If a C++ class is GTY-ed, or is pointed by a field inside a GTY-ed struct, and if
that class contains for example a PPL data (or simply if a GTY-ed struct contains a PPL
data) we need to have the PPL destuctor invoked when Ggc release the struct.

To be more specific, if you want to associate trees with PPL coefficients (in a way
visible to several passes, so using Ggc), you will declare in C 

struct GTY (()) treewithcoef_st {
    tree tr;
    ppl_Coefficient_t co;
};

it will leak, because <ppl_c.h> requires that when the field co is no more useful, it
should be released with 
  ppl_delete_Coefficient (p->co);
[since actually ppl_Coefficient_t is an opaque non null pointer to some C++ class of PPL]

and, assuming the struct treewithcoef_st is used in several passes, the sure way to know
when to delete is is thru the Ggc collector (if we always knew when exactly to destroy our
treewithcoef_st we won't use GTY on them). Si you want the Ggc collector to call
ppl_delete_Coefficient, and there is no simple way to do that today.

There is however a contrived way (used inside MELT), thru the plugin hooks: manage the
set of such struct treewithcoef_st (perhaps in a linked list, or an hash table, or a VEC,
or whatever), and
  use the PLUGIN_GGC_START & PLUGIN_GGC_MARKING event, possibly also PLUGIN_GGC_END
  add the GTY((mark_hook("some_marking_hook_for_treewithcoef")) gengtype annotation 
  to struct treewithcoef_st
at the PLUGIN_GGC_END event, scan this collection of struct treewithcoef_st and call
ppl_delete_Coefficient on approriate elements.

With finalizer inside Ggc, we could make that much simpler & more efficient (because the
PLUGIN_GGC_* tricks essentially reimplement a mark & sweep collector for our struct
treewithcoef_st): we could allocate our struct treewithcoef_st by giving a finalizer for
them which calls ppl_delete_Coefficient (p->co)

and later we could even enhance gengtype to be able at least to give the finalizer, or
even to support C++ objects with non-trivial destructors.

And indeed, using PPL data shared between several passes is my main motivation.

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} ***


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