Heap in Turbo C 2.0

[Joe English]

schikore at mentor.cc.purdue.edu (Dan Schikore) writes:

>Is there any way to measure the actual space left on the heap in Turbo C?
>The way I understand it, coreleft() is not an accurate measure if I have
>free'd some of the memory.

Not really.  Even if you were able to figure out how much 
space is left in the free list, that information wouldn't 
do you any good since the heap may be fragmented and not
all of it would be available as a contiguous chunk.

>Similarly, when I malloc and an address is returned, as far as I know the
>actual size of the block allocated may be more than I ask for.  Can I find
>out how large a specific block returned by malloc is??

It's best to assume that malloc returns exactly as much
as you asked for (if it succeeds, that is.)  

It sounds like you're having a problem with really tight memory
requirements.  You may find it useful to do your own memory
management instead of relying on malloc() for every request.
Some techniques I've found useful:

* If you have a tree- or graph- based structure and you're
  mallocking lots of nodes, write a special-purpose node allocator
  that grabs a big chunk of memory and gives out node-sized pieces
  one at a time.  You can also maintain a linked list of freed
  nodes.

* For data structures that grow monotonically, but by various
  sizes (for example, if you're processing a text file one line
  at a time) a structure that I call a "pile" is useful.  (It's
  midway between a stack and a heap.)  Again, you malloc off 
  a big chunk of memory, and add data to the end of the pile
  only.  When you hit the end of the chunk, malloc another 
  chunk and start using that one instead.  When you're
  through using the entire entity, you free() all of the
  previously allocated chunks.

The basic idea is that special-purpose allocators can be more
efficient and use less overhead than general-purpose allocators.
If memory is tight, you should look into better allocation schemes
instead of trying to take advantage of various quirks in the
'malloc' implementation.


--Joe English

  jeenglis at alcor.usc.edu