Re: [boost] request for interest in a garbage collection library

Subject: Re: [boost] request for interest in a garbage collection library
From: Achilleas Margaritis (axilmar_at_[hidden])
Date: 2009-05-02 05:15:26

David Abrahams wrote:
> on Mon Apr 20 2009, Achilleas Margaritis <axilmar-AT-gmail.com> wrote:
> 
>> Beman Dawes wrote:
>>> On Fri, Apr 17, 2009 at 4:08 AM, Achilleas Margaritis <axilmar_at_[hidden]> wrote:
>>>>> I think the question David was asking is; if a GC object is holding a
>>>>> mutex that is currently holding a lock, then when does that lock
>>>>> release, or how does that lock release? The GC may run in the future,
>>>>> and in the meanwhile, that lock is frozen.
>>>>>
>>>> Aren't scoped locks a better way to handle such issues? The big advantage of
>>>> C++ is scoped construction/destruction.
>>> Achilleas, you are missing Dave and Sid's point. It is a common and
>>> very appropriate programming practice to place resources like files
>>> and mutexes in an object and to dynamically allocate that object. If
>>> GC is used to reclaim the containing that object, then sub-objects it
>>> contains like mutexes or files that release on destruction may not get
>>> released soon enough. You need to address this concern. Telling folks
>>> not to place non-memory resources in types that may be dynamically
>>> allocated isn't likely to fly.
>> If objects like files and mutexes are dynamically allocated, then they
>> are deleted at some point, aren't they? 
> 
> I'm not sure how to answer that.  In a correct program without GC, yes,
> they are.
> 
>> so, if the programmer wants to add garbage collection to these
>> objects, so he/she doesn't have to manually track memory, he/she can
>> replace the delete operations with RAII
> 
> Sorry, I don't know what "replace the delete operations with RAII"
> means.
> 
>> and let the GC handle the memory part.
>>
>> The order or finalization is not a solvable problem by any means, so I
>> don't see how a solution can be provided. In c++, the order of
>> creation is not guaranteed to be the same to the order of allocation,
>> so it is not possible to have a real generic solution for that.
>>
>> Still, RAII can easily replace delete calls: instead of deleting an
>> object, you simply close it or unlock it and you let the gc decide if
>> the object is reachable or not.
> 
> You're still missing the point.
> 
> We went through this discussion in great detail in the C++ committee;
> let me try to sketch it for you:
> 
> Without GC, I can write a class X that manages a non-memory resource and
> frees that non-memory resource in its destructor.  The fact of that
> non-memory resource can be an implementation detail of the class; no
> client of X ever needs to know, so long as their program doesn't leak
> memory.  X can be placed in a container, aggregated into other objects,
> etc., and none of those other objects needs to know it manages a
> non-memory resource.
> 
> People commonly believe a GC'd environment gives them the right to leak
> dynamically-allocated objects without worry. If you add GC to C++, the
> fact that a type (or some other type it owns, etc.) manages a non-memory
> resource is no longer an implementation detail, because you have to know
> about the presence of that resource in order to know whether you can
> leak objects of that type.  So in C++ with GC, you don't have a blanket
> right to leak a dynamically-allocated object.

I don't think that's a great problem. I am not proposing to add GC to 
C++. I am proposing a GC solution to boost, to sit alongside shared_ptr 
and weak_ptr.

The problem you are mentioning is real, but very small. In all of my 
programming career, I have never seen an implementation detail like a 
mutex lock not be documented.

The reason is that even with destructors, you have to take care of your 
non-memory resources in order not to introduce problems like deadlocks etc.

> 
> It also means that you can't come along later and add a non-memory
> resource as an implementation detail to any class, because someone might
> be legitimately leaking objects of that type, and the resource won't be
> freed.  So unless you know that a class will *never* need such a
> resource (e.g. a mutex), you can't afford to leak it.

I think this is a design issue and therefore a solution should not be 
forced.

> 
> Therefore, "don't worry about delete; it's taken care of" is not a
> legitimate programming guideline for C++ with GC.  The question is,
> 
> ********************************************************************
> * what /is/ the guideline that explains when I can afford to leak? *
> ********************************************************************
> 
> The best we could come up with in general was, "do everything exactly
> the same way you were doing it before GC came along," at which point the
> only benefit of GC seems to be that it may keep a program that leaks
> from running out of memory as soon as it would have otherwise.  That's a
> pretty marginal benefit, it seems to me.
> 

Yes, I believe that as well: with or without GC, the semantics of a C++ 
program should not be changed.

But the benefit is not marginal, as you say. GC solves a lot of problems 
and, most importantly, increases productivity.