Path: utzoo!utgpu!attcan!uunet!husc6!mailrus!umich!itivax!scs
From: scs@itivax.UUCP (Steve C. Simmons)
Newsgroups: comp.lang.c++
Subject: Exception Handling (was: Overloading operator new())
Summary: heap vs. stack, alloca vs. malloc, new vs. ??
Keywords: garbage collection scope
Message-ID: <301@itivax.UUCP>
Date: 10 Oct 88 13:28:02 GMT
References: <5949@june.cs.washington.edu> <294@itivax.UUCP> <797@nih-csl.UUCP> <298@itivax.UUCP> <4370@polya.Stanford.EDU>
Reply-To: scs@itivax.UUCP (Steve C. Simmons)
Organization: Industrial Technology Institute, Ann Arbor
Lines: 53

In article <4370@polya.Stanford.EDU> shap@polya.Stanford.EDU (Jonathan S. Shapiro) writes:
>[[an excellent summary of useing overloaded new to implement
>  garbage collection in exception processing.  Heavily summarized:]]
>Exception handlers define a scope.
>Think of the heap as a temporally scoped object, where the
>instantiation of a "catch" scope logically partitions the heap into
>stuff older than that catch and stuff newer than that catch.
>Now overload all instances of New() within that scope so that the
>run-time system maintains, along with the scope information, a spare
>pointer to every object allocated with New() within that scope, along
>with a pointer to the destructor function.  Thus, associated with each
>heap scope we have a list of objects and their destructors.
>
>Now, when an error is raised or a "throw" is executed, we locate the
>scope that is thrown to and destroy all of the stack-instantiated
>objects. We then destroy dynamically allocated things in the clobbered
>scopes in an undefined order.

Deallocating the stack-instantiated objects (whether alloca or auto)
should be no issue.  Heap cleanup is the hard part.

>Now I know that there are lots and lots of problems here.  I also know
>that I don't know a lot about exception handling.  Can someone give me
>a non-flaming list of problems with this idea so that I can think on it
>further?  The big problem I see is that there is no good ordering
>constraint on the destructions.

It's not clear why order is a problem.  Could you explain?

As for other problems: I've seen PASCALs with an operator that
marks the current size of the heap.  You can later call a
reset operator that resets the heap to that size.  This reclaims
all the allocated space, but does not restore the structure of
the unreset heap.  The problem comes when you get complex lists.
Half the list was built before the mark, half afterwards.  You're
willing to give up the data newed after the mark, but your old
data is now possibly corrupt -- it may have pointers into the
area you just freed.  How do you fix it?  At least in the PASCALs
I've seen, you don't.

Now that I think about it, current C programs have the same problem
with malloc/free, don't they?

Might it be possible to create reference counts to items created
with new()?  It would add some expense to the new function (tho not
a lot), but possibly a lot of expense to the rest of the compiler
to maintain those.  It would remove any problems I can think of with
order of destruction, and garbage collection would start to look
suspiciously like fsck.
-- 
Steve Simmons		...!umix!itivax!scs
Industrial Technology Institute, Ann Arbor, MI.
"You can't get here from here."