request for interest in a garbage collection library

classic Classic list List threaded Threaded
85 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

request for interest in a garbage collection library

Achilleas Margaritis-4
Hi,

I have placed in boost vault a garbage collection library:

http://www.boostpro.com/vault/index.php?action=downloadfile&filename=gc.zip&directory=Memory&

The major features of this library are:

1) it supports threads; a thread can allocate gc objects and send them
to other threads.

2) it is 100% portable c++; only boost and stl are used.

3) gc pointers can point to middle of objects and arrays.

4) block allocation and finalization are customizable. The collector
does not do any allocation actually, it only manages blocks.

5) the collector uses the classic mark & sweep algorithm.

6) it has good (or not that bad :-)) performance. On my test machine (a
dual core Pentium at 2.5 GHz with 2 GB ram), 50000 objects out of 100000
are swept in 63 milliseconds. Of course, this is due to boost::pool :-).

7) it works with STL containers (the 'how' is described in the readme).

The zip file contains a set of unit tests, the API documentation and a
readme file which explains the inner workings and the design of the
collector.

I would appreciate it if people could take a look and share their
opinions on it.

Best regards

Achilleas Margaritis

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: request for interest in a garbage collection library

Jeffrey Bosboom
I'm very interested in portable garbage collection.

> 1) it supports threads; a thread can allocate gc objects and send them
> to other threads.

You mention in the readme that performance suffers with large numbers of
threads due to a global mutex.  Would it be possible to have collectors
specific to a thread or groups of threads (essentially giving each
thread/group of threads a piece of the heap to allocate from/manage with
GC)?

> 3) gc pointers can point to middle of objects and arrays.

I don't really understand how this works.  Would the middle of an
object/array get collected separately from the rest of it?  That seems
ridiculous, so I'm confused.

> The zip file contains a set of unit tests, the API documentation and a
> readme file which explains the inner workings and the design of the
> collector.

As is often the case, the readme could be improved.

Looking at gc_object, it seems that any class that wants to be
gc-allocated needs to inherit from gc_object.  Can this be avoided (e.g.,
so I can gc-allocate classes I can't modify)?  Can classes that do inherit
from gc_object still be stack-allocated or allocated on the free store
without garbage collection?

I'm a bit unclear as to how finalization works.  Suppose I simply want to
invoke the destructor to ensure that resources have been reclaimed (from a
class that uses RAII when stack-allocated and an explicit close() method
when heap-allocated) when the object is finalized.  How do I do that?

Despite these problems, I'm still excited to see the subject considered.

--Jeffrey Bosboom

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: request for interest in a garbage collection library

Achilleas Margaritis-4
> You mention in the readme that performance suffers with large numbers of
> threads due to a global mutex.  Would it be possible to have collectors
> specific to a thread or groups of threads (essentially giving each
> thread/group of threads a piece of the heap to allocate from/manage with
> GC)?

Yes, it is possible, by using a thread-specific ptr to hold a separate
instance of the gc context per each thread. But it will complicate the
collection process a little.

>
>> 3) gc pointers can point to middle of objects and arrays.
>
> I don't really understand how this works.  Would the middle of an
> object/array get collected separately from the rest of it?  That seems
> ridiculous, so I'm confused.

An object should not be collected if there is a pointer to anywhere in it.
In other programming languages that pointers to the middle of objects are
not allowed, this is not an issue.

>
>> The zip file contains a set of unit tests, the API documentation and a
>> readme file which explains the inner workings and the design of the
>> collector.
>
> As is often the case, the readme could be improved.

Sure. If there is enough interest and if there are any specific topics that
need to be addressed, please feel free to indicate them.

>
> Looking at gc_object, it seems that any class that wants to be
> gc-allocated needs to inherit from gc_object.  Can this be avoided (e.g.,
> so I can gc-allocate classes I can't modify)?

There are three ways to add garbage collection to an object:

1) inherit from gc_object<T>.
2) wrap your class in gc_wrapper<T>.
3) allocate your object with new(T_deleter)..

But you should modify your pointers to be gc_ptr<T> instances for this to
work.

> Can classes that do inherit
> from gc_object still be stack-allocated

Yes. The member pointers of stack allocated objects will be considered as
root pointers.

> or allocated on the free store
> without garbage collection?

Only if you use placement new/delete.

>
> I'm a bit unclear as to how finalization works.  Suppose I simply want to
> invoke the destructor to ensure that resources have been reclaimed (from a
> class that uses RAII when stack-allocated and an explicit close() method
> when heap-allocated) when the object is finalized.  How do I do that?

If your object is stack allocated, you don't have to do anything.

If you want to customize the finalizer, you specialize the template
gc_finalize<T> for your type,
and perform any finalization in the function. The default behavior of
gc_finalize<T> is to invoke the destructor.

You can always delete the object at any time or manually collect garbage to
release any resources.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: request for interest in a garbage collection library

Kasra Nassiri(Math & ComSci)
In reply to this post by Achilleas Margaritis-4

>> 3) gc pointers can point to middle of objects and arrays.

>I don't really understand how this works.  Would the middle of an
>object/array get collected separately from the rest of it?  That seems
>ridiculous, so I'm confused.

hi,

I think the following if what was ment:

base of array 'x'
|
v
[ 0 ][ 1 ][ 2 ][ 3 ][ 4 ] // an array of 5 elements
                 ^
                 |
                 pointer to 4-th element (ptr)

{c++} gc_free(ptr);

remove the entier object 'x' from memory so you don't have to
make sure you have a base pointer to 'x' to delete 'x'.

This comes handly for example when:

{c++[
  char* x = (char*)gc_malloc(5);
  char* end = x + 5;
  set_zero(x, 5);

  while(x != end && *x != 0) {
    // error, x should have been al zero
    gc_free(x); // note x doesn't point to base
    // of the allocated memory anymore!
  }

]}


With Best Regards

-- Kasra


     

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: request for interest in a garbage collection library

Mathias Gaunard-2
In reply to this post by Achilleas Margaritis-4
Achilleas Margaritis wrote:

> There are three ways to add garbage collection to an object:
>
> 1) inherit from gc_object<T>.
> 2) wrap your class in gc_wrapper<T>.
> 3) allocate your object with new(T_deleter)..
>
> But you should modify your pointers to be gc_ptr<T> instances for this to
> work.

So, comparing your framework to C++/CLI:
- new(T_deleter) is like gcnew
- gc_ptr<T> is like T^
- inheriting from gc_object<T> is like declaring a class as being a ref
class

Is that right?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: request for interest in a garbage collection library

Achilleas Margaritis-4
Mathias Gaunard wrote:

> Achilleas Margaritis wrote:
>
>> There are three ways to add garbage collection to an object:
>>
>> 1) inherit from gc_object<T>.
>> 2) wrap your class in gc_wrapper<T>.
>> 3) allocate your object with new(T_deleter)..
>>
>> But you should modify your pointers to be gc_ptr<T> instances for this
>> to work.
>
> So, comparing your framework to C++/CLI:
> - new(T_deleter) is like gcnew
> - gc_ptr<T> is like T^
> - inheriting from gc_object<T> is like declaring a class as being a ref
> class
>
> Is that right?

Indeed.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: request for interest in a garbage collection library

Dave Abrahams
In reply to this post by Achilleas Margaritis-4

on Mon Apr 13 2009, Achilleas Margaritis <axilmar-AT-gmail.com> wrote:

> I would appreciate it if people could take a look and share their
> opinions on it.

I haven't looked at it, but IMO the biggest obstacle to effective GC for
C++ isn't the lack of a library (Boehm's collector is pretty good
AFAIK).  It's the lack of a programming model that integrates
destructors and peoples' legitimate expectations that they will be
called to release non-memory resxources.  What can you say about the
non-memory resources owned by a GC'd object that contains, say, a mutex?

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: request for interest in a garbage collection library

Achilleas Margaritis-4
David Abrahams wrote:
> on Mon Apr 13 2009, Achilleas Margaritis <axilmar-AT-gmail.com> wrote:
>
>> I would appreciate it if people could take a look and share their
>> opinions on it.
>
> I haven't looked at it, but IMO the biggest obstacle to effective GC for
> C++ isn't the lack of a library (Boehm's collector is pretty good
> AFAIK).

I have to disagree with that. According to Boehm himself
(http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcinterface.html):

"The C++ interface is implemented as a thin layer on the C interface.
Unfortunately, this thin layer appears to be very sensitive to
variations in C++ implementations, particularly since it tries to
replace the global ::new operator, something that appears to not be
well-standardized. Your platform may need minor adjustments in this
layer (gc_cpp.cc, gc_cpp.h, and possibly gc_allocator.h). Such changes
do not require understanding of collector internals, though they may
require a good understanding of your platform. (Patches enhancing
portability are welcome. But it's easy to break one platform by fixing
another.) "

I have tried to use the Boehm GC in C++ and there were many problems:

1) can not be integrated with threading libraries such as Qt threads or
boost threads. For example, under Windows, Boehm GC supposes you use
Win32 threads, and it provides functions that replace Win32 calls.

2) the replacement of the global operator new creates many problems with
  3rd party libraries which provide their own operator global new (MFC,
for example).

3) there are few details on what is supposed to work with dlls and
globals initialized before main(). I tried asking on the newsgroup, they
did not know the answer. They said that it's platform specific, and
sometimes allocating objects before main is ok, sometimes it is not,
sometimes you have to call gc_init(), sometimes you have not to etc.

I can point you to the relevant discussions on the boehm gc newsgroup,
if you wish.

> It's the lack of a programming model that integrates
> destructors and peoples' legitimate expectations that they will be
> called to release non-memory resxources.  What can you say about the
> non-memory resources owned by a GC'd object that contains, say, a mutex?
>

Personally, I don't see why resources like mutexes or files should be
managed like memory. Resources like that are "binary" resources: they
have two states (locked/unlocked, opened/closed), which is perfectly
suited for RAII.

Can you please elaborate on the problem of destructors? I have read some
papers that say that gc and destructors don't play well together, but I
did not really agree with that. An example would be appreciated.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: request for interest in a garbage collection library

Sid Sacek-3
>> It's the lack of a programming model that integrates
>> destructors and peoples' legitimate expectations that they will be
>> called to release non-memory resxources.  What can you say about the
>> non-memory resources owned by a GC'd object that contains, say, a
mutex?
>>

>Personally, I don't see why resources like mutexes or files should be
>managed like memory. Resources like that are "binary" resources: they
>have two states (locked/unlocked, opened/closed), which is perfectly
>suited for RAII.


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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: request for interest in a garbage collection library

Achilleas Margaritis-4
Sid Sacek wrote:

>>> It's the lack of a programming model that integrates
>>> destructors and peoples' legitimate expectations that they will be
>>> called to release non-memory resxources.  What can you say about the
>>> non-memory resources owned by a GC'd object that contains, say, a
> mutex?
>
>> Personally, I don't see why resources like mutexes or files should be
>> managed like memory. Resources like that are "binary" resources: they
>> have two states (locked/unlocked, opened/closed), which is perfectly
>> suited for RAII.
>
>
> 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: request for interest in a garbage collection library

Vicente Botet

Achilleas Margaritis-4 wrote
Sid Sacek wrote:
>>> It's the lack of a programming model that integrates
>>> destructors and peoples' legitimate expectations that they will be
>>> called to release non-memory resxources.  What can you say about the
>>> non-memory resources owned by a GC'd object that contains, say, a
> mutex?
>
>> Personally, I don't see why resources like mutexes or files should be
>> managed like memory. Resources like that are "binary" resources: they
>> have two states (locked/unlocked, opened/closed), which is perfectly
>> suited for RAII.
>
>
> 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hi,

The user can use already RAII on its application. Suppose that you have a RAII class X that is garbage collected (inherits from gc_object<X>) that holds a mutex (or a file handle) and lock (open) it on construction and unlock (close) on destruction.

How the following behaves?

scoped_ptr<X> p(nex X());

When the unlock (close) function will be called?

Does it means that classes like X should not inherit from gc_object<X> and the user of X must decide whether the new X() must be garbage collected or not?

What are the criteria X must satisfy to inherit from gc_object<X> without any trouble?

The GC RAII combination rises clearly some issues, and the user must be aware of them. The question is, what the GC library can provide to the user to make user life easier and safer.

HTH,
Vicente

Reply | Threaded
Open this post in threaded view
|

Re: request for interest in a garbage collection library

Edward Diener-3
In reply to this post by Achilleas Margaritis-4
Achilleas Margaritis wrote:

> David Abrahams wrote:
>> on Mon Apr 13 2009, Achilleas Margaritis <axilmar-AT-gmail.com> wrote:
>>
>>> I would appreciate it if people could take a look and share their
>>> opinions on it.
>>
>
>> It's the lack of a programming model that integrates
>> destructors and peoples' legitimate expectations that they will be
>> called to release non-memory resxources.  What can you say about the
>> non-memory resources owned by a GC'd object that contains, say, a mutex?
>>
>
> Personally, I don't see why resources like mutexes or files should be
> managed like memory. Resources like that are "binary" resources: they
> have two states (locked/unlocked, opened/closed), which is perfectly
> suited for RAII.

Jumping in here, the problem is that having to mix GC code, which
automatically releases memory in a non-deterministic way, and normal
RAII destructor code, which releases all resources in a deterministic
way, creates two different syntaxes in a C++ program. This would
currently require the programmer to "know" which type of destruction
belongs with which object.

Unless the same external syntax can automatically be used on all
objects, where the classes of those objects which need deterministic
destruction automatically use RAII destruction whereas the classes of
those objects which only need non-deterministic destruction use GC, I do
not think C++ programmers will ever be enthusiastic about using a
garbage collector. At least I know that I won't and will stick with
shared_ptr with the occasional scoped_ptr/weak_ptr until a way to
syntactically unite RAII and GC is accomplished.

GC has successfully masked the fact, in langages/environments like
Python, Ruby, Java, .Net, that it is a very poor system for dealing with
any resource other than memory.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: request for interest in a garbage collection library

Beman Dawes
In reply to this post by Achilleas Margaritis-4
On Fri, Apr 17, 2009 at 4:08 AM, Achilleas Margaritis <[hidden email]> 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.

--Beman
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: request for interest in a garbage collection library

Jonas Persson
In reply to this post by Achilleas Margaritis-4
Achilleas Margaritis skrev:
> Can you please elaborate on the problem of destructors? I have read some
> papers that say that gc and destructors don't play well together, but I
> did not really agree with that. An example would be appreciated.

One example is that, by default, your gc do not handle cyclic
dependencies correct because destructors are run when collected.

The following example gives an access violation on windows:

----------------------------------------------
   class Foo : public gc_object<Foo> {
   public:
     gc_ptr<Foo> m_next;
     std::string m_name;

     Foo(std::string name) : m_name(name) {}

     ~Foo() {
       m_next->lastGoodbye();
     }

     void lastGoodbye() { std::cout << "Bye " << m_name; }
   };
   void test_cycle() {
     gc_ptr<Foo> foo1 = new Foo("foo 1");
     foo1->m_next = new Foo("foo 2");
     foo1->m_next->m_next = foo1;

     foo1 = 0;
     gc::collect();
   }
----------------------------------------------

   / Jonas

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: request for interest in a garbage collection library

Bastek
In reply to this post by Edward Diener-3
> Jumping in here, the problem is that having to mix GC code, which
> automatically releases memory in a non-deterministic way, and normal
> RAII destructor code, which releases all resources in a deterministic
> way, creates two different syntaxes in a C++ program. This would
> currently require the programmer to "know" which type of destruction
> belongs with which object.
>
> Unless the same external syntax can automatically be used on all
> objects, where the classes of those objects which need deterministic
> destruction automatically use RAII destruction whereas the classes of
> those objects which only need non-deterministic destruction use GC, I do
> not think C++ programmers will ever be enthusiastic about using a
> garbage collector. At least I know that I won't and will stick with
> shared_ptr with the occasional scoped_ptr/weak_ptr until a way to
> syntactically unite RAII and GC is accomplished.
>
> GC has successfully masked the fact, in langages/environments like
> Python, Ruby, Java, .Net, that it is a very poor system for dealing with
> any resource other than memory.

The way of releasing resources may be dependent on the type of
object.

If you use my GC (http://sourceforge.net/projects/sgcl), you can
write:

class Foo {};
class Bar : public Limited {};

gc<Foo> foo = gcnew Foo;
gc<Bar> bar = gcnew Bar;

Bar-class destructor will be called in a deterministic way.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: request for interest in a garbage collection library

Mathias Gaunard-2
In reply to this post by Jonas Persson
Jonas Persson wrote:

> The following example gives an access violation on windows:
>
> ----------------------------------------------
>   class Foo : public gc_object<Foo> {
>   public:
>     gc_ptr<Foo> m_next;
>     std::string m_name;
>
>     Foo(std::string name) : m_name(name) {}
>
>     ~Foo() {
>       m_next->lastGoodbye();
>     }
>
>     void lastGoodbye() { std::cout << "Bye " << m_name; }
>   };
>   void test_cycle() {
>     gc_ptr<Foo> foo1 = new Foo("foo 1");
>     foo1->m_next = new Foo("foo 2");
>     foo1->m_next->m_next = foo1;
>
>     foo1 = 0;
>     gc::collect();
>   }

So that library overloads operator new, meaning all memory becomes
garbage collected, unlike what I understood from what was answered to
one of my other posts.
I even wonder how gc_ptr<T>::gc_ptr::(T*) can be a safe constructor at all.

A fairly terrible design, that has a lot of shortcomings, some of which
where raised when talking of Boehm GC (basically, bad integration).

The funny thing is that the right way to do GC in C++ has been known for
a long time, but for some reason people still want to do it some other way.
C++/CLI, despite its evilness, does it right. Bastek's library (SGCL)
seems to do it somewhat right too.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: re quest for interest in a garbage collection library

Achilleas Margaritis-4
In reply to this post by Vicente Botet
Vicente Botet Escriba wrote:

>
>
> Achilleas Margaritis-4 wrote:
>> Sid Sacek wrote:
>>>>> It's the lack of a programming model that integrates
>>>>> destructors and peoples' legitimate expectations that they will be
>>>>> called to release non-memory resxources.  What can you say about the
>>>>> non-memory resources owned by a GC'd object that contains, say, a
>>> mutex?
>>>
>>>> Personally, I don't see why resources like mutexes or files should be
>>>> managed like memory. Resources like that are "binary" resources: they
>>>> have two states (locked/unlocked, opened/closed), which is perfectly
>>>> suited for RAII.
>>>
>>> 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.
>>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
>>
>
>
> Hi,
>
> The user can use already RAII on its application. Suppose that you have a
> RAII class X that is garbage collected (inherits from gc_object<X>) that
> holds a mutex (or a file handle) and lock (open) it on construction and
> unlock (close) on destruction.
>
> How the following behaves?
>
> scoped_ptr<X> p(nex X());
>
> When the unlock (close) function will be called?
>
> Does it means that classes like X should not inherit from gc_object<X> and
> the user of X must decide whether the new X() must be garbage collected or
> not?
>
> What are the criteria X must satisfy to inherit from gc_object<X> without
> any trouble?
>
> The GC RAII combination rises clearly some issues, and the user must be
> aware of them. The question is, what the GC library can provide to the user
> to make user life easier and safer.
>
> HTH,
> Vicente
>
>

The gc'd objects can be deleted any time, and therefore RAII works on
gc'd objects as well.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: request for interest in a garbage collection library

Achilleas Margaritis-4
In reply to this post by Beman Dawes
Beman Dawes wrote:

> On Fri, Apr 17, 2009 at 4:08 AM, Achilleas Margaritis <[hidden email]> 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? 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 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: request for interest in a garbage collection library

Achilleas Margaritis-4
In reply to this post by Edward Diener-3
> Jumping in here, the problem is that having to mix GC code, which
> automatically releases memory in a non-deterministic way, and normal
> RAII destructor code, which releases all resources in a deterministic
> way, creates two different syntaxes in a C++ program. This would
> currently require the programmer to "know" which type of destruction
> belongs with which object.

I think the overhead of knowing which type of destruction belongs to
which object is minimal when compared to the overhead of manually
tracking memory. Resources like memory should be tracked by a GC,
resources like mutexes or files should be tracked by RAII.

What I like in C++ is that I can use the best of both worlds at the same
time.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: request for interest in a garbage collection library

Achilleas Margaritis-4
In reply to this post by Jonas Persson
Jonas Persson wrote:

> Achilleas Margaritis skrev:
>> Can you please elaborate on the problem of destructors? I have read
>> some papers that say that gc and destructors don't play well together,
>> but I did not really agree with that. An example would be appreciated.
>
> One example is that, by default, your gc do not handle cyclic
> dependencies correct because destructors are run when collected.
>
> The following example gives an access violation on windows:
>
> ----------------------------------------------
>   class Foo : public gc_object<Foo> {
>   public:
>     gc_ptr<Foo> m_next;
>     std::string m_name;
>
>     Foo(std::string name) : m_name(name) {}
>
>     ~Foo() {
>       m_next->lastGoodbye();
>     }
>
>     void lastGoodbye() { std::cout << "Bye " << m_name; }
>   };
>   void test_cycle() {
>     gc_ptr<Foo> foo1 = new Foo("foo 1");
>     foo1->m_next = new Foo("foo 2");
>     foo1->m_next->m_next = foo1;
>
>     foo1 = 0;
>     gc::collect();
>   }
> ----------------------------------------------

But gc'd objects are are not supposed to touch other gc'd objects in
their destructor (if you check the readme, I explicitly say that the
order of finalization is random). Is there a realistic need to call
another gc'd object from a destructor?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12345