Why garbage collector could not be implemented in c++ ?
Hi,
I just came across a statement that says
On searching more about it, I found the following explanation
here : https://www.quora.com/Why-is-it-not-possible-to-implement-a-Garbage-collector-for-C++-C
In the above eg., we can have two scenarios,
[1] Union is used to store 'x', in which case no garbage collection is needed.
[2] Union is used to store 'p'; in this case 'p' can either be an address of a stack variable, in which case there is no role for garbage collector to play; in other case 'p' can be a pointer to dynamically allocated int, in which case 'p' will be destroyed (hence reference to dynamically allocated int will also reduce by 1) when union object goes out of scope, and the garbage collector can do its job.
I am not able to comprehend how the above example shows that GC can't be implemented in c++.
[a] Could someone please elaborate on above example ?
[b] Are their any other constraints that make it impossible to implement GC for c++ ?
Thanks for help :)
I just came across a statement that says
| Garbage collector can not be implemented in c++ |
On searching more about it, I found the following explanation
here : https://www.quora.com/Why-is-it-not-possible-to-implement-a-Garbage-collector-for-C++-C
Consider the case of a Union, one can have multiple possible interpretations of the content of memory, and so one cannot know (Mr Turing tells us so) whether the contents of the union is a pointer or an integer. |
In the above eg., we can have two scenarios,
[1] Union is used to store 'x', in which case no garbage collection is needed.
[2] Union is used to store 'p'; in this case 'p' can either be an address of a stack variable, in which case there is no role for garbage collector to play; in other case 'p' can be a pointer to dynamically allocated int, in which case 'p' will be destroyed (hence reference to dynamically allocated int will also reduce by 1) when union object goes out of scope, and the garbage collector can do its job.
I am not able to comprehend how the above example shows that GC can't be implemented in c++.
[a] Could someone please elaborate on above example ?
[b] Are their any other constraints that make it impossible to implement GC for c++ ?
Thanks for help :)
[a]
You are taking the example too language-literally.
The point is that the GC has no idea whether a piece of memory it is looking a is an x or a p or a q.
There are some good heuristics that will help it to guess well, and function well. For example, if x/p/whatever is a value that could be taken as a valid p into a known memory pool, then there is an improved probability that it is a pointer to that pool. Examine the memory pool and see if it has a block allocated matching p.
The problem is not the normal stuff, it is the exceptional stuff. What if my GC is running a complex mathematical process for my graduate study on graph traversal over extra large hash sets, and a garbage collected value looks like a p I legitimately obtained for use elsewhere? And that p is currently modified to the head of an abstract string structure with hidden state at (address_of( p ) - 16)?
GC could screw me over, and a week's worth of number crunching on the school's server could be lost.
It is exactly because C and C++ does not have any introspection that the GC has to make very clever guesses, and what makes designing one for such a language is so hard.
There are two common idioms to handle the lack of introspection:
• Add introspection by using a GC memory pool specifically.
Items you get from the pool are designed with GC, and so it does not apply to everything.
COM/OLE is an example of this.
• Avoid it by using proper RAII.
This is the method that most C and C++ people will suggest, including myself.
By properly handling your resources, you don’t need a GC.
The RAII method also has the purely-deterministic characteristic, which is a very nice feature that GCs typically lack.
[b]
At the very top of the article it notes very plainly that GCs do exist for C and C++, and they work very well. They typically do so by very intrusively analyzing your program, both data and code. This is often considered something of a black art, and strikes a lot of people the wrong way, but a lot of code in the wild does similar stuff to accomplish magic goals.
Hope this helps.
You are taking the example too language-literally.
The point is that the GC has no idea whether a piece of memory it is looking a is an x or a p or a q.
There are some good heuristics that will help it to guess well, and function well. For example, if x/p/whatever is a value that could be taken as a valid p into a known memory pool, then there is an improved probability that it is a pointer to that pool. Examine the memory pool and see if it has a block allocated matching p.
The problem is not the normal stuff, it is the exceptional stuff. What if my GC is running a complex mathematical process for my graduate study on graph traversal over extra large hash sets, and a garbage collected value looks like a p I legitimately obtained for use elsewhere? And that p is currently modified to the head of an abstract string structure with hidden state at (address_of( p ) - 16)?
GC could screw me over, and a week's worth of number crunching on the school's server could be lost.
It is exactly because C and C++ does not have any introspection that the GC has to make very clever guesses, and what makes designing one for such a language is so hard.
There are two common idioms to handle the lack of introspection:
• Add introspection by using a GC memory pool specifically.
Items you get from the pool are designed with GC, and so it does not apply to everything.
COM/OLE is an example of this.
• Avoid it by using proper RAII.
This is the method that most C and C++ people will suggest, including myself.
By properly handling your resources, you don’t need a GC.
The RAII method also has the purely-deterministic characteristic, which is a very nice feature that GCs typically lack.
[b]
At the very top of the article it notes very plainly that GCs do exist for C and C++, and they work very well. They typically do so by very intrusively analyzing your program, both data and code. This is often considered something of a black art, and strikes a lot of people the wrong way, but a lot of code in the wild does similar stuff to accomplish magic goals.
Hope this helps.
If you are talking about adding it to the language itself (not as something sitting on top or to the side of the language as an optional tool, as it is now):
GC adds a lot of overhead, and the best possible outcome of adding it to the language is that it makes code that had bugs in it work better. Its worst possible outcome is that it makes bug free code slower. Or to rephrase that, it punishes good code in favor of 'fixing' bad code. That is a terrible justification for adding something to a language. The fix here is to have programmers learn to code correctly, not pollute the language's key feature (performance).
GC adds a lot of overhead, and the best possible outcome of adding it to the language is that it makes code that had bugs in it work better. Its worst possible outcome is that it makes bug free code slower. Or to rephrase that, it punishes good code in favor of 'fixing' bad code. That is a terrible justification for adding something to a language. The fix here is to have programmers learn to code correctly, not pollute the language's key feature (performance).
Last edited on
C++11 added something related to garbage collection but I've never spent any time to figure out how it works (if it works at all).
https://en.cppreference.com/w/cpp/header/memory#Garbage_collector_support
https://en.cppreference.com/w/cpp/header/memory#Garbage_collector_support
Topic archived. No new replies allowed.