C++ and garbage collection

C++ and garbage collection

[Enrico Weigelt]

Hi folks,


I'm currently working on an complex C++ application (which I, if it
would have to be rewritten from scratch, would do in Java instead ;-o)
and I wonder whether it's possible to move to an garbage collection
in smaller steps. For now there're some parts using some "autopointer"
class (didn't deeply look into it, but I guess it's overloading
the pointer operations and doing some reference counting, which
of course isn't generally complete - would keep ring structures
forever ;-o).

My idea is to add some mark+sweep gc (boem-gc ?) and remove (or
somehow disable) all delete operations. Does that work safely,
or do I have to cope with certain nasty side effects ?


thx
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: C++ and garbage collection

[Florian Weimer]

* Enrico Weigelt:

> My idea is to add some mark+sweep gc (boem-gc ?) and remove (or
> somehow disable) all delete operations. Does that work safely,
> or do I have to cope with certain nasty side effects ?

Performance might change.

Object lifetimes are no longer deterministic, and destructors will not
be called.  This can be a significant issue.

There are a few cases when the Boehm-Dehmers-Weiser collector won't
work, for instance if you have got custom memory allocators or use
some pointer encoding schemes.

Re: C++ and garbage collection

[Enrico Weigelt]

* Florian Weimer <fw@deneb.enyo.de> wrote:

Hi,

> > My idea is to add some mark+sweep gc (boem-gc ?) and remove (or
> > somehow disable) all delete operations. Does that work safely,
> > or do I have to cope with certain nasty side effects ?
> 
> Performance might change.

Okay, it might block a little time when the GC runs, but as it's
a menu-driven application, this won't matter much, IMHO.

> Object lifetimes are no longer deterministic, and destructors will not
> be called.  This can be a significant issue.

Yes, for examples having to close fd's before unmounting filesystems.
But these places are quite few, already identified and mostly
encapsulated, so I can easily add an direct close (independent of
object lifetimes) instead of the delete operations.

> There are a few cases when the Boehm-Dehmers-Weiser collector won't
> work, for instance if you have got custom memory allocators or use
> some pointer encoding schemes.

That's not the case in my app. Purely C++, plus some additional
libraries which I could review quite easily.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: C++ and garbage collection

[Jonathan Wakely]

On 4 February 2011 19:46, Enrico Weigelt wrote:
>
> in smaller steps. For now there're some parts using some "autopointer"
> class (didn't deeply look into it, but I guess it's overloading
> the pointer operations and doing some reference counting, which
> of course isn't generally complete - would keep ring structures
> forever ;-o).

Do you mean std::auto_ptr?

Re: C++ and garbage collection

[Lawrence Crowl]

On 2/4/11, Enrico Weigelt <weigelt@metux.de> wrote:
> I'm currently working on an complex C++ application (which I, if it
> would have to be rewritten from scratch, would do in Java instead ;-o)
> and I wonder whether it's possible to move to an garbage collection
> in smaller steps. For now there're some parts using some "autopointer"
> class (didn't deeply look into it, but I guess it's overloading
> the pointer operations and doing some reference counting, which
> of course isn't generally complete - would keep ring structures
> forever ;-o).
>
> My idea is to add some mark+sweep gc (boem-gc ?) and remove (or
> somehow disable) all delete operations. Does that work safely,
> or do I have to cope with certain nasty side effects ?

If your problem is leaking memory, and you aren't playing games
with your pointers, then you can just add in the Boehm collector,
leaving the deletes in place.  This approach will leave the program
working pretty much as before, but with less memory.

If your problem is using objects after you have freed them, then you
have a much harder problem.  Many C++ programs do real work in the
destructors (like closing files) and removing the delete operations
would disable that code.  One viable approach is to modify the uses
of pointers into shared_ptr (from TR1 or boost) and then add the
Boehm collector.  This process takes work, because changing all
pointers won't work and changing none won't buy you anything.

-- 
Lawrence Crowl

Re: C++ and garbage collection

[Enrico Weigelt]

* Lawrence Crowl <crowl@google.com> wrote:

> If your problem is leaking memory, and you aren't playing games
> with your pointers, then you can just add in the Boehm collector,
> leaving the deletes in place.  This approach will leave the program
> working pretty much as before, but with less memory.
> 
> If your problem is using objects after you have freed them, then you
> have a much harder problem. 

I simply want to get rid of the whole deallocation issue at all
(never having to care about this anymore, making the code smaller
and so easier to maintain).

> Many C++ programs do real work in the destructors (like closing
> files) and removing the delete operations would disable that code.

As said in my prev. mail: these are only few cases where this 
matters (files on external storages which are mounted/unmounted
by the application) - these are only few, well known places,
which I easily could refactor.

> One viable approach is to modify the uses of pointers into shared_ptr
> (from TR1 or boost) and then add the Boehm collector.  This process
> takes work, because changing all pointers won't work and changing
> none won't buy you anything.

Guess this would take a lot of work and add more dependencies
(than just the relatively small boehm-gc lib) ...


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: C++ and garbage collection

[Jonathan Wakely]

On 05/02/2011, Enrico Weigelt wrote:
>
>> One viable approach is to modify the uses of pointers into shared_ptr
>> (from TR1 or boost) and then add the Boehm collector.  This process
>> takes work, because changing all pointers won't work and changing
>> none won't buy you anything.
>
> Guess this would take a lot of work and add more dependencies
> (than just the relatively small boehm-gc lib) ...

GCC includes a tr1::shared_ptr so there's no extra dependency if you
are only planning to use g++, and std::shared_ptr is part of C++0x.

Re: C++ and garbage collection

[Enrico Weigelt]

* Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 05/02/2011, Enrico Weigelt wrote:
> >
> >> One viable approach is to modify the uses of pointers into shared_ptr
> >> (from TR1 or boost) and then add the Boehm collector.  This process
> >> takes work, because changing all pointers won't work and changing
> >> none won't buy you anything.
> >
> > Guess this would take a lot of work and add more dependencies
> > (than just the relatively small boehm-gc lib) ...
> 
> GCC includes a tr1::shared_ptr so there's no extra dependency if you
> are only planning to use g++, and std::shared_ptr is part of C++0x.

How does that one actually work and what do I have to do to use it ?


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: C++ and garbage collection

[Florian Weimer]

* Enrico Weigelt:

>> GCC includes a tr1::shared_ptr so there's no extra dependency if you
>> are only planning to use g++, and std::shared_ptr is part of C++0x.
>
> How does that one actually work and what do I have to do to use it ?

What's the oldest GCC version you're targeting?

Modern GCC has std::unique_ptr (zero-overhead pointer wrapper with
RAII semantics), std::shared_ptr and std::make_shared (avoiding a
separate allocation using operator new).  This should work after some
adjustments, as long as your data structures are acyclic.  You just
have to avoid taking short-cuts to optimize things, using references
and plain pointers instead of the std:: wrappers.  In this regard,
Boehm GC is hard to beat.

Re: C++ and garbage collection

[Enrico Weigelt]

* Florian Weimer <fw@deneb.enyo.de> wrote:
> * Enrico Weigelt:
> 
> >> GCC includes a tr1::shared_ptr so there's no extra dependency if you
> >> are only planning to use g++, and std::shared_ptr is part of C++0x.
> >
> > How does that one actually work and what do I have to do to use it ?
> 
> What's the oldest GCC version you're targeting?

Quite old, still some 3.x (can have a look when I'm back in office
tomorrow ...)

> Modern GCC has std::unique_ptr (zero-overhead pointer wrapper with
> RAII semantics), std::shared_ptr and std::make_shared (avoiding a
> separate allocation using operator new).  This should work after some
> adjustments, as long as your data structures are acyclic.  You just
> have to avoid taking short-cuts to optimize things, using references
> and plain pointers instead of the std:: wrappers.  

We make quite heavy use of references.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: C++ and garbage collection

[Florian Weimer]

* Enrico Weigelt:

>> What's the oldest GCC version you're targeting?
>
> Quite old, still some 3.x (can have a look when I'm back in office
> tomorrow ...)

> We make quite heavy use of references.

I think you might be better off with the Boehm GC option, on both
counts.

Re: C++ and garbage collection

[Enrico Weigelt]

* Florian Weimer <fw@deneb.enyo.de> wrote:

> >> What's the oldest GCC version you're targeting?
> >
> > Quite old, still some 3.x (can have a look when I'm back in office
> > tomorrow ...)
> 
> > We make quite heavy use of references.
> 
> I think you might be better off with the Boehm GC option, on both
> counts.

Okay, that alreay was my first guess :)
Are there some nasty side effects I should be aware of ?
What about optimizations, can they be harmful here ?


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: C++ and garbage collection

[Jonathan Wakely]

On 5 February 2011 14:46, Enrico Weigelt wrote:
>> >
>> >> One viable approach is to modify the uses of pointers into shared_ptr
>> >> (from TR1 or boost) and then add the Boehm collector.  This process
>> >> takes work, because changing all pointers won't work and changing
>> >> none won't buy you anything.
>> >
>> > Guess this would take a lot of work and add more dependencies
>> > (than just the relatively small boehm-gc lib) ...
>>
>> GCC includes a tr1::shared_ptr so there's no extra dependency if you
>> are only planning to use g++, and std::shared_ptr is part of C++0x.
>
> How does that one actually work and what do I have to do to use it ?

#include <tr1/memory>

int main()
{
  using std::tr1::shared_ptr;

  shared_ptr<int> p(new int);
  *p = 5;
  assert( *p == 5 );
  shared_ptr<int> p2(p);
  assert( p == p2 );
  assert( p.use_count() == 2 );
  p.reset();
  assert( p.use_count() == 0 );
  assert( p2.use_count() == 1 );
} // int deleted here

for more info read the docs for boost::shared_ptr (where the class
originated) or search the web, there is plenty of info on shared_ptr.