Re: adding destroyable objects into Ggc

[Lawrence Crowl <crowl@google.com>]

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.

Can you be specific about the use case that is driving you towards
this solution?

Ian Lance Taylor <iant@google.com>
> I think this type of thing is conventionally called a "finalizer".

Basile Starynkevitch <basile@starynkevitch.net> writes:
> 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.

How is what you propose distinct from the finalization mechanism?
http://www.hpl.hp.com/personal/Hans_Boehm/gc/finalization.html

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

There is a world of difference between using manual memory management
in C and using smart pointers in C++.  The later can be handled, for
the most part, with local coding rules.  The former, not so much.
More importantly, the C++ standard library provides flexible data
structures so that programmers need not worry about either.

Basile Starynkevitch <basile@starynkevitch.net>
> My strong belief is that any *big* compiler needs some automated way
> to deal with memory (including circular references, which auto_ptr
> is not very happy about). It can be Ggc (I am not very happy of it)
> or something else.

While not entirely relevant, compiler needs a way to manage circular
relationships, but it does not need to manage circular pointers.
Programmers have gotten so accustomed to representing relationships
with pointers that the alternatives have almost been forgotten.

> And in my perception, auto_ptr are a poor man's way of implementing
> a garbage collection, it is not a way to avoid it.

Auto_ptr has known weaknesses, and has been supplanted by shared_ptr,
unique_ptr, and weak_ptr.  Even so, none of these are a "poor man's
garbage collector" as competent use of them leaves little garbage to
be collected.

Chiheng Xu <chiheng.xu@gmail.com>
> I recommend people interested in automatic dynamic memory management
> to read this book:  Garbage Collection: Algorithms For Automatic
> Dynamic Memory Management(Richard Jones,1996)
>
> The importance of garbage collection in large software project and
> why reference counting based solution is inefficient and can't be
> good general "garbage collection" mechanism is clearly explained.

I am willing to wager that the implicit assumption here is that
relationships are managed with pointers.

I am also willing to wager that the author is willing to accept a 5x
increase in memory use to get cited benefits.  While that tradeoff is
good for many applications, it is not good for all applications.

-- 
Lawrence Crowl