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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4045dbe1801294bc X-Google-Attributes: gid103376,public From: Brian Rogoff Subject: Re: Memory Management Algorithms for Hard Realtime Date: 1998/02/18 Message-ID: #1/1 X-Deja-AN: 326432613 References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: 887854034 19194 bpr 206.184.139.132 Newsgroups: comp.lang.ada Date: 1998-02-18T00:00:00+00:00 List-Id: On Wed, 18 Feb 1998, Joe Gwinn wrote: > In article , dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > > The book you talk about is, if we believe its title, about *automatic* > > memory management. > > > > There are many algorithms for allocating variable sized blocks with > > *manual* allocation/release control that have well defined worst > > case behavior. > > I wasn't planning to come along in a missile running the memory management > system, so automatic seems best. What am I missing? Automatic memory management = garbage collection, i.e., all freeing operations are done by *implicitly* by the runtime, so there are no explicit calls to free/Unchecked_Deallocation. Read the book, and this will become clear. Manual memory management is where you the programmer must explicitly invoke some freeing operation to return memory that you've allocated. It doesn't mean that you interactively free memory from a running program, as you seem to suggest. Its what you're doing now, if you are using fixed size block allocators. -- Brian