Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!hpda!hpwala!cfisun!palladium!nw
From: nw@palladium.UUCP (Neil Webber)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Task KILL for Amiga
Message-ID: <620@palladium.UUCP>
Date: 28 Jan 89 00:20:27 GMT
References: <3716@crash.cts.com> <10908@s.ms.uky.edu> <5713@cbmvax.UUCP> <10926@s.ms.uky.edu> <32094@tut.cis.ohio-state.edu> <619@palladium.UUCP> <2477@kalliope.rice.edu>
Reply-To: nw@palladium.UUCP (Neil Webber)
Organization: Epoch Systems, Marlborough, MA
Lines: 62

In article <619@palladium.UUCP> I wrote:

>It would do it the same way every current program is forced to 
>do it.  It won't be ANY slower.  It won't take up ANY additional memory.

referring to the OS keeping track of memory allocations.

In article <2477@kalliope.rice.edu> phil@Rice.edu (William LeFebvre) 
pointed out a possible counter-example:

>Currently, a program asks for X bytes and gets an address (i.e.: a
>pointer).  When it is done with it, it says "free X bytes starting at this
>address".  Remembering that the given address is associated with a chunk
>of X bytes is the program's responsibility.  But it's easy for the program
>to do so:  fooptr = AllocMem(sizeof(struct foo), ...);
>FreeMem(fooptr, sizeof(struct foo)). 

This is a legitimate counter example, given the way I worded my claim.
In the fine USENET tradition, I glossed over too many details.

I was referring to what calls (such as malloc()/free()) layered
on top of AllocMem/FreeMem already do to return all the memory
to the OS upon program exit.

In the case of calling AllocMem/FreeMem directly, the overhead
is less obvious, but still there.  The call:

	FreeMem(fooptr, sizeof(struct foo))

takes up memory.  For any given application program we could compute
the overhead implicit in all the FreeMem calls. This computation
would be tricky: sometimes one FreeMem call code can serve to free
multiple pieces of memory (if the call is in a loop, or in a shared
pure procedure).  Sometimes there will be multiple FreeMem call code
instances for serving a single piece of memory (i.e., FreeMem calls
duplicated in error path cleanup).  

Another (very real) form of memory overhead is when an application
forgets to call FreeMem :-)

What I'm really getting at is that you have to consider the entire
system when assessing the tradeoffs for and against a given feature.
The lack of resource tracking, in my opinion, has the *appearance*
of making the system faster and smaller.  I believe that when you
take the entire system, including application programs, into account,
you would find that the advantage is largely an illusion.  And, as
we all know, there are concrete disadvantages:

	- no KILL
	- increased burden on application developers.

Have you spent any time tracking down "where did I forget to free
this memory" bugs?  That's part of the cost of no resource tracking.
And it is multiplied by a large (one hopes) development community.

I don't realistically expect any future Amiga OS to include resource 
tracking, unless it represents a major change from the current system.
I do, however, cringe whenever I see someone claim that the current
system is desirable because it is faster and more memory efficient.
-- 
Neil Webber / Epoch Systems, Marlboro MA / (508) 481-3717
        {harvard!cfisun, linus!alliant}!palladium!nw