From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,13d6cd0af0d0d769 X-Google-Attributes: gid103376,public From: ncohen@watson.ibm.com (Norman H. Cohen) Subject: Re: Does memory leak? Date: 1995/04/06 Message-ID: <3m0r01$174b@watnews1.watson.ibm.com>#1/1 X-Deja-AN: 100939394 distribution: world references: <3ls2ku$qls@hacgate2.hac.com> organization: IBM T.J. Watson Research Center reply-to: ncohen@watson.ibm.com newsgroups: comp.lang.ada Date: 1995-04-06T00:00:00+00:00 List-Id: In article , 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