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