Newsgroups: comp.lang.smalltalk,comp.object,comp.lang.c++,comp.lang.java
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!newsfeed.internetmci.com!in1.uu.net!alexandria.organon.com!alexandria!jsa
From: jsa@organon.com (Jon S Anthony)
Subject: Re: The Good, the Bad, the Ugly, and the Wicked ...
In-Reply-To: mbk@caffeine.engr.utk.edu's message of 8 Apr 1996 19:40:42 GMT
Message-ID: <JSA.96Apr9131057@organon.com>
Followup-To: comp.lang.smalltalk,comp.object,comp.lang.c++,comp.lang.java
Sender: news@organon.com (news)
Organization: Organon Motives, Inc.
References: <31570B8E.5A12@vmark.com> <4je5rq$7qg@mimas.brunel.ac.uk>
	<4jes0t$gth@decaxp.HARVARD.EDU> <31630E30.5A02@oma.com>
	<4kbq3q$1i8@gaia.ns.utk.edu>
Date: Tue, 9 Apr 1996 17:10:57 GMT
Lines: 53
Xref: glinda.oz.cs.cmu.edu comp.lang.smalltalk:37013 comp.object:47335 comp.lang.c++:183502 comp.lang.java:38558

In article <4kbq3q$1i8@gaia.ns.utk.edu> mbk@caffeine.engr.utk.edu (Matt Kennel) writes:

> Robert C. Martin (rmartin@oma.com) wrote:
> : It is neither wrong nor right.  There are certainly some real-time systems
> ...
> : In any case, it matters little.  The more intense the real-time
>...
> : one merely trades the job of managing memory, for the job of
> : managing the collector.
> 
> It is not a trade, as nearly all garbage collection systems still
> *allow* manual memory management.

Right.  And for many RT systems you _don't_ want any "dynamic" memory
allocation (as you hint below) or at the least, any that is not
completely under your control.


> : Malloc and new can *always* be made to be deterministic.  That is
> : one of the major attractions to manual memory management in 
> : real time systems.  You can use malloc/free (new/delete) pairs which are
> : 100% predictable.
> 
> Are they?  Have you gone through the all the possible orderings of
> previous 'new' and 'malloc' so that you ***KNOW*** exactly
> what the internal heap structures are so that subsequent calls to 
> 'malloc' and 'new' and 'free' take a known amount of time?

Actually, it is even worse than you are suggesting as Malloc/new and
free are not necessarily very predictable and can exhibit "bad" behavior
depending on their use.

> Thus the distinction should not be "GC" vs "malloc" but really
> 
> "GC or malloc" vs "static fixed storage."

Well, this depends on what you mean.  If you have control over your
allocation pool and its allocation/deallocation resources (for example
user defined storage pools in Ada95), you can have "dynamic storage"
which is not malloc, GC _or_ "fixed" storage.  Assuming, of course,
that you don't count under "fixed" the need for the initial block of
memory for your pool (which could be _static_ or not).

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

