Re: adding destroyable objects into Ggc

[Richard Guenther <richard dot guenther at gmail dot com>]

On Fri, Oct 21, 2011 at 10:56 PM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> 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.

Same as in C.  If you have a pointer to malloc() memory in a GTY-ed
struct it will leak.
Which is why in the GTY world there is a dont-do-that rule, instead
you need to put
your malloc memory in GC space, too.

Thus, not a C++ limitation, but a general issue with mixing GC and
non-GC things.

Now complicated things more and make the malloc region point to GC memory again
and you'll see why generally mixing GC/non-GC things isn't the very best idea.

> 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]

Don't do that then.

Richard.