storage management

[Eric Dean Tribble <tribble>]

I've been thinking a bit about storage management stuff.  Yesterday I
had a short conversation with Mr Hill.  I asked Hill for a mechanism
to let me delete everything allocated inside a DYNAMIC scope (later in
a call chain) when I leave the scope.  In response he mentioned
possibly making nested episode objects.

That comment made an idea for the interface finally gell: statically
declare a heap object.  All objects allocated at or below that scope
get allocated in that scope's heap.  When the heap goes out of scope,
it destroys itself. These resemble Lifetime objects for more than one
object. More permanent objects can either be made, then promoted out
of the heap, or explictly allocated on a different heap (using the
fluid binding trick currently implemented).  The promotion operation
is essentially: "ensure that object O is in a heap with a longer
lifetime than heap H."  

I've thought of 3 kinds of heaps that would be really useful:

1) heaps that contain the space in which to put their objects.  These
would get used for large episode heaps.  These make lots of sense when
you don't deallocation and allocation to reflect the number of objects
referenced.  This places very strict requirements on what kinds of
finalization actions objects can take, since the destructors will
never actually be called.  Do Necromancers provide an alternative
finalization mechanism for objects that can work with this?

2) indirect heaps.  These allocate the actual data in another heap but
keep track of the pointers so that all the objects get destroyed when
the indirect heap gets deleted.  These are very much an extension of
Lifetimes, amortizing the cost of the Bomb over several objects.

3) fast, small heaps.  These are for little objects allocated in inner
loops.  Several of these might be preallocated.  They contain the
space and really optimize speed at the expense of space.  I'm not sure
how different these are from the others.  I would want to use this for
objects allocated in Iterator loops, for example.  I KNOW those will
be a hot spot.

These keep reminding me of space banks from KeyCos and the heap
objects used in Glockenspiel.  I'm sure they provided the germ of the
idea.  Now that we know much more about storage issues in C++ should
we revisit the heap stuff in Glockenspiel?  I can imagine several
variations on the above semantics.  Which one would be best?  How much
impact do they have on our coding style? :-) How much work will
retrofitting be (especially if we wait 'til after Beta)?  Etc.

I was also thinking about gross hacks for reusing objects, but I'd bet
the above heap stuff will make that unnecessary.  

I wanted to start this discussion now because Mr Hill has and will be
spending a fair bit of time adding delete message to things.  Such
delete messages have two problems: they make the code far less
readable, and they don't cleanup if something BLASTs.
DYNAMIC_LIFETIMEs are too heavy to use in general, and they don't help
with allocation of objects internal to loops and such.  (they should
be renamed to TEMPs - far more readable) Since storage management is
likely to be one of our nightwares, investing in abstractions for it
will be well worth the while!!!

dean