Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!mintaka!wookumz.gnu.ai.mit.edu!rjc
From: rjc@wookumz.gnu.ai.mit.edu (Ray Cromwell)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: re^4:what to buy??(numbercruncher)
Message-ID: <1991Jun21.235106.14465@mintaka.lcs.mit.edu>
Date: 21 Jun 91 23:51:06 GMT
References: <1991Jun20.160839.28053@mintaka.lcs.mit.edu> <82@ryptyde.UUCP> <5333@dirac.physics.purdue.edu>
Sender: news@mintaka.lcs.mit.edu
Organization: The Internet
Lines: 67

In article <5333@dirac.physics.purdue.edu> sho@gibbs.physics.purdue.edu (Sho Kuwamoto) writes:
>In article <82@ryptyde.UUCP> dant@ryptyde.UUCP (Daniel Tracy) writes:
>>>  Question: Why do you have to specify a size to the Mac OS? What's
>>>the point?"
>>
>>I believe I understand the difference now. Amiga applications take memory
>>dynamically as they need it. Macintosh applications, having been bred in
>>a single-tasking environment, instead check how much memory is available
>>and use it all. Under Mac Multitasking, you tell the OS how large a 
>>contiguous chunk to give the application. Then when the application checks
>>to see how much memory it has, it gets returned a value proportional to how
>>much you specified. Interesting. Am I right?
>
>Sort of.  Applications don't assume they hog the whole machine, but
>the memory manager has a hard time with non-contiguous space.  This is
>because the mac uses relocatable chunks of memory.  I don't see why
>that *must* be so.  I can see that using non-contiguous space would be
>inefficient as hell, but I don't see why it would be impossible.  If
>all blocks stayed put, that's a different story.

  From the way I interpret this, the Mac has some form garbage collection
to prevent memory defragmentation. I get the suspicous feeling that
the MacOS was developed originally in a language other than C, something
with a run-time memory manager and garbage collector. Am I right?
I see nothing but disadvantages in this type of memory system for
modern computers
   1) Double indirection of pointers is slower
    (yes you can lock a memory block, but why use handles in the first place?
     I know I would be irritated if I had to constantly do a 
	ptr1->ptr2->mystuff when coding)

   2) garbage collection is expensive and it gets worse depending on
     the amount of memory you have and the amount being used

 On modern computers an MMU can be used to defrag memory and private
memory pool managing can reduce it greatly. Can someone tell me
why Apple uses this type of memory management?

>Ok.  Now for the flip side.  If you need more memory than you have,
>you can make a call to the OS to allocate memory outside your
>application zone.  This area should only be used for temporary
>storage, but it helps out a lot.  For example, the Finder uses
>temporary memory to buffer while copying files.  Once the file copying
>is done, it lets go of the memory.
>
>It's not transparent to the programmer, but it's not horrible, either.
>All you need to do is to call TempNewHandle() instead of NewHandle().
>In addition, you can afford to give applications more space with
>virtual memory.  It's not ideal, but it is a step in the right direction.

  It still seems strange that you have to 'limit' or tell the OS
the maximum memory your app will need. The only thing that is close
to this on the Amiga is the need to predefine the stack size
(this is because 68000,68010, 68020 w/o MMU cannot have dynamic
stack growth without checking the stack constantly before pushing
anything on it, this slows down code a lot and places burdens on the
compiler)

>-Sho
>-- 
>sho@physics.purdue.edu


--
/ INET:rjc@gnu.ai.mit.edu     *   // The opinions expressed here do not      \
| INET:r_cromwe@upr2.clu.net  | \X/  in any way reflect the views of my self.|
\ UUCP:uunet!tnc!m0023        *                                              /