C memory management

[Stan Switzer]

In article <29996 at bu-cs.BU.EDU> bzs at bu-cs.BU.EDU (Barry Shein) writes:
> Some Pascals (maybe all?) supported a possible compromise where you
> called a routine "mark()", did your allocs and later some sort of
> super-free which would release everything back to the last mark()
> call.  There was no need to call all in the same routine, just so long
> as mark() was called earlier than the allocs and free. It could work
> either stackwise (my preference) or take some sort of magic cookie to
> identify which mark to clear back to (probably useful before a longjmp
> after an error condition.)

PostScript programmers will recognize this as "save" and "restore."

It works well enough for a page description language, but it is a bit
strained for more general applications.  Consequently, NeWS adopts a
reference-counting scheme and all but ignores "save" and "restore."
Display PostScript augments "save" and "restore" with mark-and-sweep
garbage collection ("save" and "restore" are problematic with multiple
processes).

I almost used a similar scheme in a C-like compiler I once wrote but
the increment portion of the "for" loop made me think better of it.
Still, you might justify bracketing the compilation of each procedure
with a save() and restore().  I ended up doing it the hard way.

My conclusion is that save() and restore() might work pretty well for
certain kinds of programs and less well for others.

Here's how I'd do it in C:

  AllocClass allocclass = save( parentclass );
  void *mem = smalloc( allocclass, size );
  restore( allocclass );

The save() function would create a new allocation class.  If
parentclass were null, it would be an independent allocation class,
otherwise it would be a subsidiary class of the specified parent.

The smalloc() function would allocate memory from the specified class.

The restore() function would free all memory allocated in the
specified classes and, recursively, all subsidiary classes and the
memory alloced from them.

A simpler scheme would forgo the allocation class business entirely,
allowing a very simple stack-based memory manager.

This scheme might work pretty well for an interesting class of
programs, but is by no means a panacea.

Stan Switzer  sjs at ctt.bellcore.com