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 Tue, 18 Oct 2011 09:35:16 -0700
Ian Lance Taylor <iant@google.com> wrote:

> Basile Starynkevitch <basile@starynkevitch.net> writes:
> 
> > I would like to add destroyable objects into Ggc (the GCC garbage collector, see files
> > gcc/ggc*.[ch]).
> 
> I think this type of thing is conventionally called a "finalizer".

Yes, if you like it. However both Boehm's GC and Java GC attach a more specific (and
perhaps more powerful) meaning to that term.

> I'm ambivalent leaning to negative to adding this feature to the gcc
> garbage collector.  In the long run I would like to use the gcc garbage
> collector less and less.  I believe that we can use C++ smart pointers
> to move in that direction.  


As far as I understand, we don't move much towards that direction. tree-s, gimple-s,
gimple_seq-s, edge-s, are still managed by Ggc (and on that particular aspect things
don't seem to change in the trunk, it is the same as in GCC-4.4, GCC-4.5, GCC-4.6: these
data types need Ggc.).

I believe I will be able to manage the MELT runtime to use whatever memory management the
community will agree upon (otherwise, it would mean that MELT is dead). In the worst
case, the MELT plugin would provide its self-sufficient GC (currently MELT GC is backed up
by Ggc: the MELT GC is copying generational, and its old generation is the Ggc heap).

But [independently of MELT] I don't believe that GCC will be able to return to manual
memory management. There have been valid reasons (long time ago) to implement Ggc, and as
far as I understand GCC, I don't see these reasons becoming invalid, on the contrary. I
don't like much the implementation of Ggc [in particular, I badly dislike the lack of
support for local variables in it], but I do believe that a five-million line compilers
(or 8MLOC, depending how you count them) with a community of hundreds of developers badly
need an automated way to deal with memory.

Did you notice any recent changes in Gcc which decrease the utility of Ggc?

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]