Re: Garbage Collection - The Trash Begins To Pile Up
Ion Gazta?aga wrote:
I've used leak detectors with C/C++ for 20+ years. The first generally
available (and still available) one is one I wrote and gave away 20
years ago: http://c.snippets.org/code/mem.txt They certainly help debug
memory allocation problems - but they don't make it any easier to
*design* robust memory management. They also don't guarantee correctness:
1) if you don't have a 100% comprehensive test suite
2) for every path an exception might take through your code
3) for threading issues
4) for code you have to work with that cannot be instrumented
5) for code you have to work with that uses different memory management
conventions
1) and 2) are not very convincing for me, because RAII its in our
hands.
RAII is good for a certain class of simple problems, but is not a
general panacea for exception handling cleanup problems. For more
information, see http://www.digitalmars.com/d/exception-safe.html
Of course, I can make mistakes, but if instead of using char[],
I use std::string, I'm pretty sure that no memory will be leaked even
every single statement of my function throws an exception. But I
understand your points.
You've a potential resource leak every time you use operator new, and a
potential dangling pointer problem every time you use RAII. For example,
just store a reference to an RAII stack allocated std::string into a
global map.
If you have memory that you don't know when it will be freed, it's
clear that GC is a good option. C++ should definitely have it. But I do
think that most memory allocations have an easy, single owner lifetime,
and that can be easily managed using constructors and destructors (or
even better, with a member auto_ptr/unique_ptr<>). The single ownership
can be efficiently transferred through unique_ptr<>.
For shared ownership, if we need to deterministically free resources
(for example, when all the users of a net connection end their job we
want to close the connection) shared_ptr<> is a good option, because
the destructor will be called when the last reference dies.
And hopefully, you carefully did all the auto_ptr/unique_ptr/shared_ptr
decisions correctly, along with the transfers. Then when someone else
comes along and modifies your code, they don't botch that all up by
failing to understand all the subtle details of when to use which ptr type.
For memory with uncertain or too complicated lifetime, GC is the right
option. The problem is that, IMHO, making GC the default choice is not
a good option. Although in theory GC *can* improve memory use, I think
most of the problems with GC have relationship with a) finalization b)
excessive memory use. And that's maybe because garbage collection is
being used for tasks that are more efficiently (without any effort,
like using unique_ptr/auto_ptr in single owner memory) handled with
manual management.
GC isn't good for non-memory resource handling. I think a large part of
the problems people have with GC come from trying to bash it to handle
resources like file handles for which it is eminently unsuitable.
Essentially, if you need a destructor/finalizer, then you shouldn't be
using GC to manage it.
But the fortunate reality is that the vast majority of destructors are
needed to manage memory, and those can be dispensed with with GC.
My experience is that both Java and Managed C++ desktop applications
consume much more memory than their previous C++ incarnations. I'm not
talking about old applications or environments and I'm not the only one
with this feeling. But of course, this is only an impression and it's
not a fact.
I don't know about Managed C++, but a big factor with Java memory
consumption is the lack of support Java has for POD and stack allocated
data. It forces too much onto the heap.
My fear is not related with adding GC to C++ but with *how* it will be
added. And which are the implications of "optional". For the moment, I
can only see one proposal, and IMHO that proposal can silently break my
old code, because my code was based in deterministic resource
liberation and manual management. I would prefer a C++/CLI-like
approach, because it's less intrusive and because creating a garbage
collector that can eat pointer xor-ing, pointer operations like < or
==, and storing pointers inside any memory type, does not seem an easy
task without paying some performance price (I'm not an expert, so don't
take this statement too seriously).
How I am supposed to write a generic code that can be used in
environments both without GC (I must explicitly call delete[]) and with
GC (no deterministic finalization, must call dispose manually) ? Should
I write two control paths checking std::is_garbage_collected() at
runtime?
I agree with your concerns there. I think it is too late for C++ to go GC.
So, based on your experience, do you think that transparent garbage
collection (N2128, new/delete garbage collected, scanning for pointers
in integers if the class is not gc_strict, operator < and == with
pointers, using pointers as hash keys...) can have performance issues
or algorithm limitations comparing to a C++/CLI-like approach (a
different pointer type, the compiler forbids castings on those
pointers...)?
There is no C++ finalization proposal yet AFAIK, and I think that
having GC without solving finalization is not desirable. Which is, in
your opinion, the best way to deal with finalization issues that have
arisen in other languages (Java problems, for example, are mentioned
N2128)?
The problems happen like when one decides that object-oriented
programming is the One True Path, and then tries to bash everything into
being an object. GC is not the One True Path. But it works well enough
for a large set of common problems. But when you need finalizers,
destructors, or to close file handles, GC is the wrong answer. The four
general forms of memory management are:
1) explicit
2) RAII
3) reference counting
4) GC
C++ supports 1,2,3, D supports 1,2,4. There's some ongoing investigation
between myself and colleagues on a way to support 3 in D, and then the
programmer will be able to select the right approach for the right problem.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]