Experiences w/ Garbage Collection and C/C++?

dberger queries: "Java has helped garbage collection enter the mainstream programmer's life - but it's certainly not new or unique to java. There have been (and are) several ways to add garbage collection to C/C++ - the most active seeming to be Hans Boehm's free libgc. I'm curious if any of the Slashdot crowd has used this (or any other) C++ garbage collector in non-trivial commercial applications. If so - what were your experiences? If not, why not? (Before you ask, yes - I know that GC isn't the only difference between C++ and Java, but 'automagic memory management' is certainly part of Java's marketing luster)"

Certainly..

[QuantumG]

Have a look at our project Boomerang [sourceforge.net]. We're over 230k lines of code and we garbage collect everything. It's as easy as linking to Hans Boehm's libgc and adding the following lines to one of your files (probably best is the one which contains "main").

void* operator new(size_t n) {
return GC_malloc(n);
}

void operator delete(void* p) {
}

You can also mix collected memory with uncollected memory, but we really don't see the point. This way we can still have descructors which do useful things but the actual memory clean up is left to the garbage collector. Of course, as we write more and more new code we leave our deletes and our destructors out, and eventually we'll go through and remove them all. Until then, we can disable the garbage collector just by #if 0ing these lines out.

Re:Certainly..

[AJWM]

leave our deletes and our destructors out,

If you have destructors, do they ever get called? Destructors aren't just for freeing memory, they're also used for freeing other system resources (depending on the object). File descriptors, database connections, that kind of stuff. (Granted, you can have explicit methods to take care of that cleanup, but then you can have explicit methods to free memory too. Seems to me you want all that as automatic as possible.)

Re:C++ very expressive indeed

[lovelace]

So please tell me what

typedef vector::const_iterator Iter;

(or rather vector::const_iterator) is supposed to mean. I suppose vector is a templated class, but how does ::const_iterator come up with a type name -- I thought :: either references a static field or a class member function?

No, classes can have types too. In this case, a vector::const_iterator is an iterator over the vector type that can point to anything in the container (the vector) but cannot change anything in it. A read-only pointer, if you will.

And what is the deal with the sort(,) as a free-standing function? Following OO principles, shouldn't the vector object v know how to sort itself with a call to v.sort()? And what the heck is this const_iterator type anyway that you can do ++ and * on it -- looks an awful lot like a pointer -- oops, I forgot, you can overload ++ and * to make "safe" operations on what are really objects look like "dangerous" pointer operations which the C/C++ community is in custom of using.

C++ is not just an OO language. It's a multi-paradigm language [amazon.com]. In addition to OO, you can also do procedural , functional or generic programming. The key is to use the right tool for the right job, not to force everything into the OO model.

As far as iterators looking like pointers, there's a reason for that. They're modeled after pointers! This way a regular pointer can be used with any generic algorithm (like sort).

C++ is not just Bach. It's the entire classical genre. Java, while nice for some things, just falls short at most things. All things do not fit into the object oriented model and trying to put them there when they don't belong is a recipe for disaster. While I disagree with your characterization of Java as Mozart, I will say this. I learned Mozart when I was a beginning music student. After too long, though, it became predictible and downright boring. There was so much more I wanted to do with music. So, I branched out to Beethoven or Strauss. From there I went to even more exotic things like Bartok or Shostikovich. I felt much more fulfilled as a musician and could express things I never could while just playing Mozart. C++ is like this. It's not just OO or procedural or functional or generic. It can be whatever you want it to be and after using it for a while, other languages just don't match up.

Re:GC costs

[Hard_Code]

Can anybody informed tell me whether we have not ALREADY lost the war against pointer-chasing and cache clobbering? Any OOP or interpreted language (the vast majority of mainstream code) is doing this already, true?

It's okay

[Anonymous Coward]

I've used a garbage collection system in a C project before and it works surprisingly well. The problem with GC in C though is that it is possible and legal to,

o allocate memory
o write the pointer to a disk
o lose the pointer in memory
o read the pointer back off the disk,
o make use of the pointer

With all GC strategies I'm aware of, by the time you read the pointer from the disk the memory may well have been freed.

I'm not saying that this style of programming is a generally good idea but it is used in certain, specialised situations and therefore not suitable for a garbage collecting language.

The wonders of moderation

[Latent Heat]

The original discussion was whether anyone used/benefited from a C++ implementation of GC. A poster responded with a link to Stroustrup pointing out that C++ is so expressive that you don't need GC -- you can embed the memory management in stack-frame objects which take care of it for you.

I pointed out that Stroustrup's example shows the expressive power of C++, but there is a big "huh?" factor of reading the code on account that many of us mere mortals are not rehearsed in the use of templates and STL, and there was something to be said for Java and GC, not just for safety but for simplicity of expression and code reading by maintenance programmers.

Yours is one of three comments to my remarks, answering questions I had raised, disagreeing with some points, agreeing with others, but otherwise engaging in a reasoned discussion of the merits of C++ and its advanced features (templates and STL). But I get moderated down and flagged "troll" -- oh well.

Re:Use More Manageable Types

[Javagator]

I was part of a project to write an image display system of about 100k lines of C++ code. Our coding standards required that we allocate resources in constructors, release them in destructors, and put objects on the stack when possible. When putting objects on the stack was not possible, we used smart pointers.

Towards the end of the project, we finally got our company to spring for Purify. We ran Purify on the code and found a few places where we forgot to release a graphics context, and one place where we didn't follow our coding standards, but no other memory leaks. We than ran purify on a comparable C system and found hundreds of memory leaks.

Proper use of constructors and destructors can make resource management virtually automatic.

Re:Use More Manageable Types

[WatertonMan]

Depending upon how you are using Java, you end up having to do a lot of things that end up being managed garbage collection anyway. i.e. not that different from C/C++ except that when you screw up you don't end up with a memory leak.

If you use a tool like boundschecker and run it a couple of times a day, you'll avoid most of these sorts of problems in C++. It's an amazing tool I couldn't live without. One advantage to having these sorts of things flag as a "memory leak" is that you can often find subtle bugs that way.

Admittedly because of the issue of pointers vis a vis Java, that's less of an issue in Java. But I'm not sure merely adding garbage collection is ideal in most cases.

If you are writing high enough code that you really want garbage collection, the advantages of writing in C++ over Java are probably slight. (The speed advantage isn't that big a deal anymore and many programs don't really need that slight speed advantage anyway) If you are writing code that benefits from the fine control C++ offers you'd probably not want to trust garbage control so the point is moot.

I'm not saying there aren't cases where garbage control is useful. However I halfway wonder if these situations wouldn't be better handles by a combination of languages. i.e. Java and C or Python and C. Code your important functions in C or C++ and put the main interface/io functions in the higher level language.

Re:There's another way.

[Anonymous Coward]

Actually, GC *eases* the issues associated with recovering memory in multithreaded systems. Why? In a multi-threaded program with manual deallocation, both allocation and deallocation occur in every thread context. In a GC system, all deallocation is typically concentrated in a single thread, the GC thread. Allocation is still spread across threads but the required interlocking is hugely reduced since the GC thread can do all of the reclaiming, block coalescing and free list construction (if that's the technique used) without any interference from the other threads. It will have to acquire a mutex to place the recovered blocks back where the active threads can get them, of course.

It's amazing how moderators will usually mod up a post because it's really long and they seem to know what they are talking about.

You're 100% wrong. Garbage collection from a single thread locked by a single mutex stalls all threads wishing to allocate memory. Allocation and deallocation from a given memory arena must make use of the same mutex - i.e., memory operations across all threads effectively block. Making use of more than one memory arena is one (naive) way to work around this problem. You also have to consider cache lines to avoid stalling different threads. There's a dozen other factors as well. In the end even your best generational garbage collector is no match for a modern SMP malloc/free implementation like Hoard. Google on it.