On Thu, 20 Oct 2011, Basile Starynkevitch wrote:
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.
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
