[gclist] Destructors in a heap oriented language.

[David Ungar]

Uniformity is so important that I would be inclined
to be scared of any design that proposed "two kinds of storage."
How do you know which to use when?
How do things work together?
Do you really want to give up uniformity for this?

(Am I hanging crepe or what?)


At 1:18 PM 3/13/96, Charles Fiterman wrote:
>Let us assume that destructors are important. That the program needs
>to run them and do so quickly or it is buggy. A good example is a
>file handle leak which is clearly worse than a storage leak.
>
>I think the trick is to establish stack semantics for objects with
>destructors.
>
>1) When a pointer is aimed at an object with a destructor its reference
>   count goes up when the pointer is reaimed or destroyed the reference
>   count goes down and zero count destroys the object. Straight reference
>   count semantics.
>
>2) Any object with a destructor or a pointer to an object with a
>   destructor is considered an object with a desturctor so the pointer`s
>   destructor`s can be called.
>
>3) Pointers to objects with destructors are either in the static area
>   or in other objects. If they are in other objects they can be set
>   in constructors but never reset. Pointers in the static area
>   can be reset, triggering destructor calls. At end of job the
>   static data area is destroyed.
>
>This gives two kinds of storage, reference count for objects with
>destructors and garbage collected for objects without. At no point
>can circular reference be created. No actions take long sequences
>to complete.

-- Dave