Re: adding destroyable objects into Ggc

[Marc Glisse <marc.glisse@inria.fr>]

On Thu, 20 Oct 2011, Basile Starynkevitch wrote:

> On Wed, 19 Oct 2011 21:17:47 -0700
> Lawrence Crowl <crowl@google.com> wrote:
>
>> Basile Starynkevitch <basile@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.

If you just let the objects leak, their destructor is not executed. 
Garbage collection reuses that memory in such a way that you can't notice 
the difference with a leak (except that you don't get OOM).

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

Or you could imagine the garbage collector also reclaiming that memory.

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

Yes, those are the usual arguments for a finalizer.

-- 
Marc Glisse