On Fri, 21 Oct 2011 10:43:29 +0200
Richard Guenther <[email protected]> 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} ***
