This is the mail archive of the 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 Wed, Oct 19, 2011 at 1:13 AM, Basile Starynkevitch
<> wrote:
> Historically, it was the opposite: I do recognize the importance of garbage collection,
> and because of the importance of Ggc in GCC, I designed MELT garbage collection above Ggc.
> 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.
> But again, if many people (not me Basile) believe that Ggc is useless, why is it not
> disappearing from the GCC trunk?
> 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.

It seems that this thread needs some balance.

Basile, I completely agree with you.

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.

As a non-compiler developer, I want to share my experience inÂstudying
 GCC's source code.
When I first read GCC's source code several years ago, I was totally
confused by the GGC markers here and there.
Basically, I just don't understand their precise meaning. And I'm
afraid I don't know how to add them.
My source code analyzer(aÂproprietary software on Windows) was also
confused/poisoned byÂtheÂGGC markers.

The result is that I crafted a script that can remove nearly
all(99.9%)ÂGGC markers in GCC source tree, then myÂsource code
analyzer and I were both happy. I also attach the scripts.

When not seeing theÂGGC markers, Âmy brain is much relaxed. ÂI can be
more focused on the logic of compiler, don't worry about memory
management issues. In this way, I found GCC's source code was not that
horrible. ÂIt turned out to be simple and easy to understand

My point is that, when a programmer don't need to worry about memory
management issue, Âhis/her productivity isÂmaximized.

Chiheng Xu

Attachment: gcc_clean_scripts.tar.bz2
Description: BZip2 compressed data

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]