Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!keith
From: keith@Apple.COM (Keith Rollin)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Explanation for incredibly slow NewPtr(and NewHandle) on ci and fx
Message-ID: <46786@apple.Apple.COM>
Date: 24 Nov 90 00:33:50 GMT
References: <649@nih-csl.nih.gov> <17354@hydra.gatech.EDU> <1990Nov23.192937.8359@nada.kth.se>
Organization: Apple Computer Inc., Cupertino, CA
Lines: 31

In article <1990Nov23.192937.8359@nada.kth.se> d88-jwa@dront.nada.kth.se (Jon W{tte) writes:
>In article <17354@hydra.gatech.EDU> gt0657c@prism.gatech.EDU (geoff george) writes:
>
>>The problem about high bits set in AllocPtr sounds like some Apple
>>programmers forgot to call _StripAddress. How delightful! 
>
>Pardon an ignorant question:
>
>Why replace the memory manager, when a patch that StripAddresses
>the AllocPtr (or whatever) when you call _NewPtr or _NewHandle ?
>Or does the problem occur within the manager and the manager
>doesn't use traps ?

The problem really only shows up in non-relocatable block allocation
(i.e. on NewPtr calls). So imagine this: you make a NewPtr call. In
order to put the block as low in memory as possible, the Memory Manager
must move all relocatable blocks out of the way. OK, so it moves the
first one. When it frees up where the block used to be, it sets
AllocPtr with the dirty bits. At this time, the hint is bad, and any
subsequent searches for free space will require a full heap search. If
you must move several relocatable blocks, they all suffer from a full
heap search. Since this occurs in a tight, self-contained loop in the
Memory Manager, there is no way to sneak in and clear the naughty
bits.

-- 
------------------------------------------------------------------------------
Keith Rollin  ---  Apple Computer, Inc.  ---  Developer Technical Support
INTERNET: keith@apple.com
    UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith
"Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions