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

Subject: Re: [boost] request for interest in a garbage collection library
From: David Abrahams (dave_at_[hidden])
Date: 2009-04-30 13:50:32

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.

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.

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.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com