Re: Does memory leak?

[ncohen@watson.ibm.com (Norman H. Cohen)]

In article <D6KtAI.JyG@inmet.camb.inmet.com>, stt@spock.camb.inmet.com
(Tucker Taft) writes: 

|> John Baker (jbaker@thor.tu.hac.com) wrote: 
|>
|> : The Lisp i programmed in (symbolics) had a really nice feature --
|> : allocation to *named* areas of memory.  You could allocate
|> : objects with differing life spans in different areas and then
|> : (at the appropriate time), wipe a whole named area and start over
|> : without having to destroy the objects individually.  Very fast
|> : and easy to control.  I'd like to see a feature like that in C++
|> : and ADA.
|>
|> This is essentially equivalent to "mark/release."

No, mark/release is for FIFO deallocation.  What John has described
allows a compiler writer, for example, to allocate data structures that
will persist over all phases of the compiler (for example aliasing
information computed by the front end and used during optimization) in
one area, and to allocate data structures that are only needed during the
first pass (for example a symbol table for nonexternal symbols) in
another area, INTERLEAVING ALLOCATIONS IN THE TWO AREAS, and then to
destroy the second area in its entirety after the first pass, leaving the
first area intact.  Mark/release would not allow the interleaving.

|>                                                    This is supported
|> in Ada 95 via user-defined storage pools.  There is an example in the
|> Ada 95 Rationale on this (see section on "Storage Pool Management").

Ada 95 does indeed solve the problem, but it is the ability to explicitly
associate different storage pools with different access types (and the
ability to control when a storage-pool object is finalized) that solves
the problem, not the addition of Mark and Release operations.

Allocation in areas (which could themselves be allocated and deallocated)
was a very useful feature of PL/I, and I'm glad to see it is not
forgotten.

--
Norman H. Cohen    ncohen@watson.ibm.com