Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!hplabs!pyramid!voder!apple!lsr
From: lsr@apple.UUCP (Larry Rosenstein)
Newsgroups: comp.sys.mac
Subject: Re: Calling MoreMasters
Keywords: memory masters handles
Message-ID: <6972@apple.UUCP>
Date: 10 Dec 87 23:56:21 GMT
References: <1987Dec7.094745.599@mntgfx.mentor.com> <3561@hoptoad.uucp>
Reply-To: lsr@apple.UUCP (Larry Rosenstein)
Organization: Advanced Technology Group, Apple Computer
Lines: 64

In article <3561@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>
>My favorite part of this tech note is the ultimate paragraph.  "This is a
>simple strategy for handling MoreMasters.  The prgram ResEdit uses a far
>more sophisticated approach, allocating master pointer blocks dynamically.
>That technique will be the subject of a future Technical Note."

I think I know what it is referring to and it is not very mysterious.

The thing you are trying to avoid is allocating a new master pointer block
while you have something else locked low in the heap.  MP blocks are
allocated as non-relocatable blocks, so the Memory Manager already puts them
as low in the heap as possible.  But if you had something else locked down
at the bottom of the heap, then the MP block might end up above it and you
would end up with a hole in your heap.

I think the technique referred to in the Tech Note is to call MoreMasters
yourself (instead of letting the system call it for you), at a time when you
are sure that it won't cause problems.  In an application, this is generally
at the event loop, when you can purge unneeded CODE segments, etc.

So what you can do is every time through the event loop check to see how
many master pointers are left, and if you are running low call MoreMasters.
The free master pointers are linked together (see page II-22 of Inside
Macintosh), so they can be counted fairly easily.

How you determine whether you are running low depends on your application.
You would have to have an idea of how many master pointers each operation
needs.  


After saying all this, I don't think this strategy is as necessary now as
when the Tech Note was written.  In 1985, people were still working with 64K
ROMs, in which the code segments were loaded low in the heap.  The 128K ROMs
and above will load code segments high in the heap (if the resources are
unlocked).  (You can also override the 64K ROM Segment Loader to achieve the
same effect; see Tech Note #39.)

If all your code segments are at the top of memory, and if you call MoveHHi
before locking any large handle, then the bottom of memory should always be
clear.  Therefore, the MP block will end up as low as possible, and you
won't get heap fragementation.  In MacApp, we ensured that segments were
loaded at the top of memory, and didn't do anything special with MP blocks.

One interesting trick we did do is that instead of calling MoreMasters
several times at the start of the program, we changed the field of the heap
zone that indicates how many masters to allocate, and called MoreMasters
once.  (Of course we changed the field back so that future allocations we of
the original size.)  

(Aside: I notived that the Tech Note on patching the Segment Loader
came out before the one on MoreMasters.  This is probably a case of
mis-communication or something.  The example given in the MoreMasters Tech
Note wouldn't be valid if code segments were loaded at the top of memory.)

-- 
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.com