eacj@batcomputer.tn.cornell.edu (Julian Vrieslander) (04/10/88)
The "standard" approach to allocating master pointer blocks is to
(empirically) determine the largest number of handles an application is
likely to need, and then to place enough calls of MoreMasters() in the
initialization code to cover that worst case. A more sophisticated
approach that I have seen described in a couple of places (including Scott
Knaster's first book) involves periodically counting the number of unused
master pointers. When you see them running low you call MoreMasters()
again, making sure to do the call when it will not cause fragmentation
(eg. from the event loop, with all segments unlocked).
That sounds like a good idea, but I am not sure how to do it in a way that
will not be broken by future changes to the master pointer format. Inside
Mac says that the unused master pointers are kept in a linked list, and
the address of the first one can be found in the heap zone header. But
the master pointers themselves are not normal pointers - the high byte is
used for flags, the low 3 bytes for the address. So it seems that special
code is needed to traverse the list. Can this be done in a way that won't
fail if the master pointer format changes? And how likely is it that the
format will change?
--
Julian Vrieslander (607)255-3594
Neurobiology & Behavior, W250 Mudd Hall, Cornell University, Ithaca NY 14853
UUCP: {cmcl2,decvax,rochester,uw-beaver,ihnp4}!cornell!batcomputer!eacj
INTERNET: eacj@tcgould.tn.cornell.edu BITNET: eacj@CRNLTHRYbayes@hpfcdc.HP.COM (Scott Bayes) (04/13/88)
How likely is the master pointer format to change? Well we changed to a 32 bit address bus architecture a couple years back. That was necessary to break past the 8M RAM barrier (in our machines, your mileage may vary). Crash, crash, crash!!! When Mac grows up, either master pointers will have to change, or something icky like bank switching will have to happen (no, no!! I'll even take an 80x86 instead!!) Scott Bayes bayes@hpfclw
darin@Apple.COM (Darin Adler) (04/15/88)
In article <11550001@hpfcdc.HP.COM> bayes@hpfcdc.HP.COM (Scott Bayes) writes: > How likely is the master pointer format to change? Master pointers will probably continue to work like they do today, except that the additional information (locked, purgeable, and resource bits) will be stored someplace other than the high byte of the master pointer. One possiblity would be allocating a second long word, either before or after the master pointer, and putting the bits there. -- Darin Adler, Apple Computer AppleLink:Adler4 UUCP: {sun,voder,nsc,mtxinu,dual}!apple!darin CSNET: darin@Apple.com
lsr@Apple.COM (Larry Rosenstein) (05/11/88)
In article <4362@batcomputer.tn.cornell.edu> eacj@tcgould.tn.cornell.edu (Julian Vrieslander) writes: > >initialization code to cover that worst case. A more sophisticated >approach that I have seen described in a couple of places (including Scott >Knaster's first book) involves periodically counting the number of unused >master pointers. When you see them running low you call MoreMasters() >again, making sure to do the call when it will not cause fragmentation >(eg. from the event loop, with all segments unlocked). I don't think you need to go to this trouble. At the time Scott wrote that tip, the Segment Loader did not automatically move segments to the top of memory, so it would be possible to fragment the heap if MoreMasters was called at a bad time. The 128K ROM and beyond Segment Loader will automatically move unlocked code segments to the top of memory before locking them. (You can also make a patch on 64K ROMs to do the same thing.) This means that low memory is always free of locked handles. Provided you don't lock one of your handles without moving it high, then it should be safe to allow the system to call MoreMasters when you run out of master pointers. >That sounds like a good idea, but I am not sure how to do it in a way that >will not be broken by future changes to the master pointer format. Inside >Mac says that the unused master pointers are kept in a linked list, and >the address of the first one can be found in the heap zone header. But >the master pointers themselves are not normal pointers - the high byte is >used for flags, the low 3 bytes for the address. So it seems that special When dealing with addresses like this, you should always use the StripAddress call to make a clean address. This works on the Mac O/S (with 24-bit addresses) and A/UX (32-bit). The other question if whether master pointers will always be linked together in the way Inside Mac describes. I don't know how likely this is to change, but note that Inside Mac only talks about the head of the list. It says nothing about how the master pointers are actually linked. In MacApp, we traverse the list of free master pointers for debugging purposes (the programmer can see if memory is being allocated but never freed). We also make sure that code segments are locked at the top of memory, and allow the Memory Manager to call MoreMasters when needed. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 27-AJ Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr