C++ Garbage Collector

Due to overcomplicated overhead maker performance killer but very flexible and reuseable design, I need to mix manual and garbage collected memory management in my C++ applications.

Because at some point I can't determine whether an object should be destroyed or not.

I think I need a help from a garbage collector.


Do you use garbage collector?

What is it?

Is it fast?

Is it easy to use (pluggable) and mixable with the manual memory management?

And unrelated question: Is smart pointer a garbage collector?

How is it work anyway?

Thanks in advance by the way.

A smart pointer is not a garbage collector. A smart pointer is usually a reference counted pointer. Each time you create an instance of the smart pointer that points to the same memory, the reference count increases. Everytime an instance to the pointer is destroyed, it decrease the count.
So when the last smart pointer goes out of scope, it frees the memory.
Check out std::tr1::shared_ptr or alternatively boost::shared_ptr.

The overhead of smart pointers are very small and fits right in into the design of C++. Smart pointers can be used exactly like normal pointers.

They also have an advantage over garbage collection: they have deterministic destructors.
What does that mean, you ask? When using a garbage collector, destructors of classes might not be run. Or if they are, it is impossible to predict when.
But with smart pointers, you know that the destructors of objects will run as soon as the last smart pointer goes out of scope.

Thank you Elysia, you are my live savior!

Btw is it guarantee to guard our code from memory leaks?

However I found auto_ptr only not the shared one..

There is one problem with smart pointers: circular references. A points to B, B points to A. This will cause memory leaks and can be solved by using a "weak pointer" in one class to break this chain.
Otherwise there will be NO leaks whatsoever.

I'm not sure if C++ has a garbage collector. I know C# and Visual Basic has a garbage collector that runs in the background.

no C++ does not have a garbage collector like VB and C#. you have to deal with the garbage yourself.

Quote:

---

Originally Posted by Jelte

no C++ does not have a garbage collector like VB and C#. you have to deal with the garbage yourself.

---

Standard C++ does not come with a garbage collector, but automatic garbage collectors are available.

I've never used it, but one of my professors told me about the Boehm-Demers-Weiser garbage collector. Apparently, you just link to it and it'll do the magic work.

Quote:

---

Originally Posted by Elysia

Otherwise there will be NO leaks whatsoever.

---

Really? What about this piece of code:

Code:

---

int main()
{
    shared_ptr< int > x = new int;

    for( ;; )
        ;
}

---

The variable x is never used, so its memory is wasted. This is called a "leak" under most definitions of "leak" I've ever seen. Reference counts can't help you if you maintain references to objects you will never use again.

This example looks silly, but in a more complicated program this can lead to actual, measurable memory leaks, i.e. the program memory size is increasing although nothing useful is occupying that memory.

Quote:

---

This example looks silly, but in a more complicated program this can lead to actual, measurable memory leaks, i.e. the program memory size is increasing although nothing useful is occupying that memory.

---

Those are actually the worst kind of memory leaks due to being very hard to track down. Tools like valgrind's memcheck don't help because the memory is correctly freed when the application shuts down, so memcheck doesn't detect it. The only program I've found to be helpful in these situations is massif (another valgrind tool) which allows you to examine the heap while the application is running.

Quote:

---

Originally Posted by bithub

Those are actually the worst kind of memory leaks due to being very hard to track down. Tools like valgrind's memcheck don't help because the memory is correctly freed when the application shuts down, so memcheck doesn't detect it. The only program I've found to be helpful in these situations is massif (another valgrind tool) which allows you to examine the heap while the application is running.

---

I've dealt with this before by slightly modifying the shared_ptr<>. Each pointer appends a pointer to itself (pointer to shared_ptr) onto a global list of pointers when it is created, and removes itself from the list when it is destroyed. This means that at any moment I have access to a list of all the shared_ptr objects in memory.

At the end of the program, right before returning from main(), the list will contain only those pointers which still have positive refcounts, i.e. they point to blocks of memory which are referenced somehow. I know that I am about to terminate, so there is no valid reason these references should still exist -- therefore they are leaks. So I traverse this list and increment the refcount of each pointer in the list. Now the memory blocks will not be deleted and memcheck can report them.

Quote:

---

Originally Posted by brewbuck

Really? What about this piece of code:

Code:

---

int main()
{
    shared_ptr< int > x = new int;

    for( ;; )
        ;
}

---

The variable x is never used, so its memory is wasted. This is called a "leak" under most definitions of "leak" I've ever seen. Reference counts can't help you if you maintain references to objects you will never use again.

This example looks silly, but in a more complicated program this can lead to actual, measurable memory leaks, i.e. the program memory size is increasing although nothing useful is occupying that memory.

---

This is no "leak" which I thought of, and I wouldn't call it a leak anyway. While x may never be used, it will be released once main ends, and if it doesn't end, then all memory, smart pointers or not will basically leak, if you terminate it somehow.
So, the shared pointer will never fail to release the memory (ie function incorrectly) so long as its destructor is run (and the scenario I stated in the reply above does not occur).
You might say that so long as the above scenario doesn't occur, the shared pointer will function according to specs. It would work as it should. If there is a memory leak still, it's not the smart pointer's fault; it's yours.

Quote:

---

This is no "leak" which I thought of, and I wouldn't call it a leak anyway. While x may never be used, it will be released once main ends, and if it doesn't end, then all memory, smart pointers or not will basically leak, if you terminate it somehow.

---

You are failing to understand his point. The point is that the application can still use up more and more memory as it goes even though smart pointers are correctly used.

Ah. That is not a leak, however. It's just you using more and more resources and not letting the program free them.
It's a good example that you need to be careful with your resource allocation, but it's not the fault of the smart pointers; it's yours.

Whether it is technically a "memory leak" or not is debatable. It has the same effect as a traditional memory leak though, so that's why Brewbuck pointed it out. And no one ever claimed it was the fault of the smart pointer.

*shrug* It was directed at my reply where I said no memory leaks. I originally did not include that definition of a leak or scenario when I wrote the reply, so we can consider them as separate issues that can cause "leaks" or other issues despite smart pointers.

Quote:

---

Originally Posted by Elysia

Ah. That is not a leak, however. It's just you using more and more resources and not letting the program free them.
It's a good example that you need to be careful with your resource allocation, but it's not the fault of the smart pointers; it's yours.

---

You seemed to be making the claim that a program which uses smart pointers can't contain memory leaks. That's just not correct.

Well, if my replies make it seem like that, then I apologize. Of course it's not the case.
Smart pointers is a tool to help avoid memory leaks; it's not a bullet proof solution.

I wonder if GC would do anything about it (how does it know it will not be used, seeing as it is in scope)?

Quote:

---

Originally Posted by anon

I wonder if GC would do anything about it (how does it know it will not be used, seeing as it is in scope)?

---

GC cannot solve this problem. The problem doesn't come from reference counts, it comes from the references themselves. No garbage collector, unless it can predict the future, can know whether or not a reference to some object will ever actually be used.

IOW, you should not have references in the root set which are never going to be used. Only the programmer can know that. Smart pointers and garbage collections aren't magical memory-leak-preventers, they are just a way to avoid the tedium of manual resource management. (And viewing either of them as an excuse to be lazy and not think about the problem is completely misinterpreting their purpose)

Quote:

---

Originally Posted by brewbuck

I've dealt with this before by slightly modifying the shared_ptr<>. Each pointer appends a pointer to itself (pointer to shared_ptr) onto a global list of pointers when it is created, and removes itself from the list when it is destroyed. This means that at any moment I have access to a list of all the shared_ptr objects in memory.

At the end of the program, right before returning from main(), the list will contain only those pointers which still have positive refcounts, i.e. they point to blocks of memory which are referenced somehow. I know that I am about to terminate, so there is no valid reason these references should still exist -- therefore they are leaks. So I traverse this list and increment the refcount of each pointer in the list. Now the memory blocks will not be deleted and memcheck can report them.

---

Reading this topic I was thinking of this exact solution. Transverse the list of all shared_ptr's and check refcounts. However, how did you get a list of shared_ptr's when they are templated? There's no generic containers (without casting). std::list<boost::shared_ptr<int>* > only works for int's, std::list<boost::shared_ptr<std::string>* > for std::string, etc. Did you void* cast? std::list<void*>

Quote:

---

Originally Posted by Dae

Reading this topic I was thinking of this exact solution. Transverse the list of all shared_ptr's and check refcounts. However, how did you get a list of shared_ptr's when they are templated? There's no generic containers (without casting). std::list<boost::shared_ptr<int>* > only works for int's, std::list<boost::shared_ptr<std::string>* > for std::string, etc. Did you void* cast? std::list<void*>

---

No, I implemented shared_ptr<> from scratch. It derives from a basic ref_counted class. So what I store in the list is pointers to ref_counted bases, not the actual shared_ptr<> types themselves.

It's obviously more difficult if you are using some third-part smart pointer which you don't want to modify.

Quote:

---

Originally Posted by brewbuck

It's obviously more difficult if you are using some third-part smart pointer which you don't want to modify.

---

Ya, unless you copy the source, rename it like gc_ptr or garbage_ptr, then modify and use that instead. I guess there's no possible way to transverse the list and delete objects which have died (have a refcount of one), because there's no way to store a list of ANY pointer (generic), and ALSO be able to know it's type when it comes to deleting it. Unless of course your smart pointer only accepted basic types, and/or types which inherit a base class (ie. class something : public garbage_collectable; boost::gc_ptr<something> s), or implement certain variables/functions (ie. typedef my_type).

For you purposes though, debugging the list of pointers, it sounds like it works perfectly.

Quote:

---

Originally Posted by brewbuck

The variable x is never used, so its memory is wasted. This is called a "leak" under most definitions of "leak" I've ever seen. Reference counts can't help you if you maintain references to objects you will never use again.

---

I definitely wouldn't call that a leak. Bad memory management? Error? Certainly.

But for a true memory leak, the program must be in a state where it CANNOT free the memory (for example, if it lost all pointers to a dynamically allocated object). In the other case, the program still has the ability to free the memory, it just hasn't done so.

Quote:

---

Originally Posted by Cat

I definitely wouldn't call that a leak. Bad memory management? Error? Certainly.

But for a true memory leak, the program must be in a state where it CANNOT free the memory (for example, if it lost all pointers to a dynamically allocated object). In the other case, the program still has the ability to free the memory, it just hasn't done so.

---

Because... that's what you say?

There is file leaks too, xP

They exists because of:
1. Abnormal processes
2. Abnormal terminations
3. You might forget about it

1)

Code:

---

int *i = new int[10];
.
.
throw ...

---

2)

Code:

---

Ctrl+Alt+Del

---

3)

Code:

---

int *i = new int[10];
.
.
return; //no delete

---

While

Code:

---

int *i = new int[10];

for(;;);

---

is exactly undefined behaviour I think. xD

Quote:

---

Originally Posted by audinue

There is file leaks too

---

What do you mean by file leaks? The first and third examples that you cited can be considered memory leaks.

Quote:

---

Originally Posted by audinue

is exactly undefined behaviour I think.

---

I think the behaviour is well defined: control goes into an infinite loop.

Quote:

---

Originally Posted by Cat

But for a true memory leak, the program must be in a state where it CANNOT free the memory (for example, if it lost all pointers to a dynamically allocated object). In the other case, the program still has the ability to free the memory, it just hasn't done so.

---

There was an article years ago that classified the various kinds of leaks one could have in a Java program. I regularly supplied it to Java newbies who proudly proclaimed that Java had "eliminated" them, freeing them from having to "worry about memory management". I believe said article classified this kind as a "loiterer". Just hanging around with nothing better to do. :-)

Been years...could be wrong about that.