C++ use of Malloc/Realloc and Free

[markw at mohawksoft.com]

> From: nmeyers at javalinux.net
> To: Glenn Burkhardt <gbburkhardt at aaahawk.com>
> Cc: BLU Discussion List <discuss at blu.org>
> Subject: Re: C++ use of Malloc/Realloc and Free
> 
> On Mon, Jun 23, 2003 at 05:48:14PM -0400, Glenn Burkhardt wrote:
>> > On Sun, Jun 22, 2003 at 04:15:57PM -0400, Jerry Feldman wrote:
>> > > > So I agree with you that using malloc/free/realloc can be quite
>> > > > dangerous, there are some occasional times where the risks
>> > > > outweigh the danger. 
>> > > Yes, you are quite correct. The bottom line is that the programmer
>> > > must understand the issues. 
>> > 
>> > Ok, I'll bite.  What are the issues?  I've not done much C++
>> > programming, but I'm curious...
>> > 
>> > - -- 
>> > Derek D. Martin
>> 
>> I don't think it's very complicated, but as always, one needs to be
>> aware of what happens.  Just make sure that if you allocate memory
>> within a class, that the destructor for the class frees it.  Sort of
>> like making sure that memory  allocated by a function is released
>> before it returns.  If pointers to  allocated memory are passed around
>> between classes, the same problems exist as for passing pointers to
>> allocated memory between C functions.  One doesn't want it freed in a
>> destructor and then used, or have it left dangling.
> 
> Constructors and destructors can do anything from manage memory to
> launch missiles - they are whatever the programmer wants to be executed
> automatically when objects go into and out of existence (either in the
> heap or on the stack). So, in the general case, it *can* be very
> complicated. Using malloc/realloc/free bypasses that mechanism and can
> completely change the function of the object. That's the issue: you
> have to understand what functionality you're short-circuiting.
> 
> Nathan Meyers
> nmeyers at javalinux.net

I have been lurking on this set of threads and I have a few notes. malloc
et. al. are also very poor for performance. The memory heap is often times a
point of contention for multi-threaded programs.

Some of the tricks are to use devices like "alloca" (under Windows this is
_alloca) which allocates memory off the stack which does not need to be
explicitly freed, it goes away when you exit the function.

Another problem with all dynamic memory allocation strategies is heap
fragmentation. In a standard use app, this isn't much of a problem, but in a
long running server, using the heap with a lot of odd sized objects can
cause little bits of allocated memory to slowly fill up the process space. 

Imagine this scenario: You allocate a 2K chunk of memory for a buffer,
allocate 1K for an persistent object, free your buffer, allocate another
object that is 1K. You just successfully wasted about 1K of memory space in
your system. As all allocation systems must use some memory to manage memory
blocks, the 1K left over isn't really big enough to satisfy a 1K allocation
request.

Over time, if this continues, your process space will grow. Eventually, you
will fill all available memory and swap, untill, ultimately, you are killed
by the user or the OS.

What is funny about this mode of death, is that the system says you are only
using a small amount of memory, and have lots of free space, but your
process is sucking up tons of system memory and swap.

If you allocated your 2K buffer with alloca, it would be just as flexable,
but would have come off the stack, and you would not have fragmented your heap.

I don't subscribe to the notion that APIs are "good" or "bad," it is just
how you use them. C/C++ is a VERY powerful toolset, but don't be surprised
when it allows you to do something bad.

If you take the time to learn the mechnics of the compiler, i.e. how it
works, so much so that it is obvious, you will never fear things like
pointers, malloc, and casts.