Re: GDB to C++ issue: deletion

[Ian Lance Taylor <ian at airs dot com>]

Paul Hilfinger <hilfingr@EECS.Berkeley.EDU> writes:

> This reminded me of an issue that I'd be curious to see discussed.
> The STL container classes are certainly convenient for decreasing
> memory leaks with little fuss, but they do so internally with
> individual frees of allocated items.  GDB currently does much of its
> allocation using a region-based style (in the form of obstacks).  This
> reduces leakage at some expense in safety (although I have not seen
> many dangling-pointer problems triggered premature obstack releases in
> GDB).  Allegedly, GDB's use of obstacks significantly speeds up
> allocation and (of course) deletion.  I have certainly seen programs
> in which the need to free data structures individually adds
> significant cost*.  The STL container classes provide for allocators,
> but I have no experience in how well they could be made to work in
> duplicating GDB's current performance in this area.

It's fairly easy to use a custom allocator for an STL object which
allocates from a memory pool.  libstdc++ has one.  The free function
simply adds the pointer to a free list.  You wouldn't want to use that
specific allocator, since it loses performance by being multi-thread
safe.  But it would be easy to simplify it.

Lots of code which uses obstacks doesn't actually free anything at
all.  It wouldn't really work to duplicate the semantics of
obstack_free in an allocator (free the specified object and all
objects allocated after it).  But it would be easy to simply ignore
calls to free--just make the allocator's deallocate function do
nothing.  In that case the memory would not go away until the
allocator itself is destroyed--or, if you prefer, the allocator could
be written to simply never release the memory at all.

Ian