Argument Against GC
From Adobe Open Source Wiki
Revision as of 22:30, 24 September 2007 by SeanParent
Use Cases for Garbage Collection in C++
- Object oriented programming - reference based objects
- Functional programming - avoiding copies of immutable objects
- Trash collection - preventing bad code from crashing or exhausting memory or address space.
Analysis of Each Use Case
- Current solutions - reference counting and pooled memory
- Look at what happens with reference counting with move semantics
- For trash collection - sight issues with trash and reference counted systems [I had a good one recently - can't find it at the moment - bug easy to google for.]
Complexity of Current GC for C++ Design
- Type qualifiers vs. modifiers vs. attribute for gc_strict and gc_relaxed - are none of these. We have no experience with such constructs and how they interact with type system.
- The proposal breaks conventions for RAII - and we have no experience or guidelines. When should one call delete?
- The gc_required and gc_forbidden keywords bifurcate the language.
- Suppress and collect must be used for critical areas of performance.
- No guidance on how multiple collectors in the same application will interact.
- Note that the vast amount of complexity necessary for GC is apparent in the number of keywords and library routines to support it. This is a strong argument that it is of little use for saving bad application - it is just as likely that GC will be misused (if not more so) then memory. Google "unmanaged pointers managed C++" for many examples. Note that as long as we support the C libraries (and C runtime) such issues will always be part of C++.
Outline a Proposal to Address Some Issues
- Eliminate gc_required
- gc_strict as a type qualifier or attribute
- Definition of a operator new() in the presence of GC
- Use of gc_strict as part of type to guide and check RAII.
- Complex solution to problem for which simple solutions are widely used and will be improved by C++0x leaving us little need.
- We have little to no experience with the recommended language features which are to be standardized.
- Fixing bad software complex system will never work.
- Recommend minor language changes to improve future GC support - disallow hiding of pointers (xor list trick) as one example.
- Finally - address the "C++ is bad because it has no GC" argument head-on. C++ doesn't generate garbage and so has no need for GC. Clearly Java, C#, Objective C, etc. generate lots of garbage.