Re: [boost] Review of a safer memory management approach for C++?

Subject: Re: [boost] Review of a safer memory management approach for C++?
From: Bartlett, Roscoe A (rabartl_at_[hidden])
Date: 2010-05-27 02:30:29

Lucanus,

> -----Original Message-----
> From: Simonson, Lucanus J [mailto:lucanus.j.simonson_at_[hidden]]
> Sent: Wednesday, May 26, 2010 6:28 PM
> To: boost_at_[hidden]
> Cc: Bartlett, Roscoe A
> Subject: RE: Review of a safer memory management approach for C++?
> 
> Bartlett, Roscoe A wrote:
> > Hello Boost developers,
> >
> > I am interested in finding one or more individuals who are
> > knowledgeable about memory management in C++ (and especially of the
> > reference-counting approach taken by boost::shared_ptr and
> > boost::weak_ptr) to review an idea for a comprehensive approach to
> > safer memory management in C++ that encapsulates all raw C++ pointers
> > in high-level code.   The technical report for the approach is:
> >
> >     Teuchos C++ Memory Management Classes, Idioms, and Related Topics
> >     The Complete Reference
> >     A Comprehensive Strategy for Safe and Efficient Memory Management
> > in C++ for High Performance Computing
> >
> > and can be found at:
> >
> >     http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf
> >
> > If someone would be willing to at least go through the abbreviated
> > table of contents laid out in the Preface and provide some feedback,
> > I would be greatly appreciative.
> 
> I note that there is no thread safety baked in yet.

[Bartlett, Roscoe A] 

As noted in Section 5.14, thread safety has not been needed in our CSE codes yet, at least not involving something as high-level as a smart pointer.  Also, I am not convinced that *every* RCP object should be thread safe.  I think there are other alternatives that will yield safe code with lower overall overhead.

> You can use boost::range instead of a reference to vector to pass an
> array safely.

[Bartlett, Roscoe A] 

You can't template a virtual function in an abstract interface on a Range type.  That means you can't use runtime polymorphism.  Are you suggesting that large application codes template their entire code base on Range types?  That is a very bad idea.  Unnecessary templating results in all types of problems such as object code bloat, long (or intractable in many cases I have seen) compile times, usability problems (e.g. SomeClass<A,B,C,...,X,Y,Z>), compatibility problems (e.g. Type<A> not compatible with Type<B>), etc.  For any non-trivial code, implicit template instantiation is not even feasible (i.e. the compiler segfaults (e.g. the Sun) or just never finishes) and we have to result to tedious and hard to maintain explicit instantiation.  There are some programming problems where templating is the best way to solve the problem but replacing:

   double * x, size_t s_size

with a templated object is not one of them, not by a long way.

Remember, all we are really trying to do is to replace the lowest level uses of (T*, size_t) with a safe alternative.  We don't need (and can't afford) the full flexibility of a templated iterator type.

> It isn't clear to me what your implementation offers that isn't covered
> by purify or library checked iterators.  If you do your own allocator
> you need to do these things to implement a debug mode.  If you use the
> system allocator them purify works.  If you use the stl then you use
> their debug mode.

[Bartlett, Roscoe A] 

A lot of data that gets allocated in a CSE application is not and cannot get allocated with STL allocators.

As for Purify, that is not a sufficient solution either for the reasons described in Section 3.2 and Section 5.11.5.  Also, Purify is a commercial product and may CSE developers simply don't have access to it (and would not know how to use it if they did is some cases).

> I don't see the point of implementing your own
> reference counted allocator and pointer object to replace the system
> allocator and raw pointer when that is the case where tools like
> valgrind and purify work.  I read your justification for why these
> tools are insufficient, but you didn't convince me that you have
> covered any cases that they would not.  It seems to me that you have
> invented a way to do manually what valgrind does automatically.  What
> am I missing?

[Bartlett, Roscoe A] 

Reference counting in ArrayRCP is critical for maintaining persisting associations (see Section 4.2 and other material), iterators can't do this.

Again, valgrind and purify have many issues and they will *never* catch the types of semantic memory usage errors described in Section 3.2.  The Teuchos Memory Management classes trivially catch many of these types of semantic usage errors.

If you put together the fact that you can't manage full templating of every large code bases on Range types and accept the fundamental short comings of memory checking tools, can you see the motivation for this approach?

I would be curious what opinions you have of some of the other material (such as design implications of the runtime handling of weak pointers).

Thanks,

- Ross