Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!oliveb!amdahl!apple!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac.programmer
Subject: Re: How do you count unused master pointers?
Message-ID: <9493@apple.Apple.Com>
Date: 10 May 88 20:29:55 GMT
References: <4362@batcomputer.tn.cornell.edu>
Reply-To: lsr@apple.UUCP (Larry Rosenstein)
Organization: Advanced Technology Group, Apple Computer
Lines: 47
Keywords: master pointers

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