tomc@mntgfx.mentor.com (Tom Carstensen) (12/07/87)
What is a good guideline as to how many times you should call MoreMasters? I've seen some programs call it about 10 times, others 7 - is there better documentation on the ROM call then that of Inside Mac? :------------------------------------------------------------: : Tom Carstensen Usenet: tomc@mntgfx.MENTOR.COM : : Mentor Graphics GEnie: : : : : . . . and this shall be Max Headroom's finest hour. : : - Max Headroom : :------------------------------------------------------------:
sho@tybalt.caltech.edu (Sho Kuwamoto) (12/08/87)
In article <1987Dec7.094745.599@mntgfx.mentor.com> tomc@mntgfx.mentor.com (Tom Carstensen) writes: >What is a good guideline as to how many times you should >call MoreMasters? I've seen some programs call it >about 10 times, others 7 - is there better documentation >on the ROM call then that of Inside Mac? > You should think about getting a good debugger like TMON. If you have one, you can start your program, give it a real good workout (open lots of windows, manipulate lots of data, etc.) and then call up the debugger. If you have a heap fragmentation problem (esp. if you have unrelocatable blocks of length $100 floating around near the middle of the heap,) you should try calling MoreMasters() a couple more times in your initialization. -Sho (sho@tybalt.caltech.edu, sho@caltech.bitnet, ...!cit-vax!tybalt!sho)
tim@hoptoad.uucp (Tim Maroney) (12/09/87)
In article <1987Dec7.094745.599@mntgfx.mentor.com> tomc@mntgfx.mentor.com (Tom Carstensen) writes: >What is a good guideline as to how many times you should >call MoreMasters? I've seen some programs call it >about 10 times, others 7 - is there better documentation >on the ROM call then that of Inside Mac? See Mac Technical Note #53, the penultimate paragraph. (Remember, you really can't do serious Mac programming without the tech notes.) Briefly, remove all your calls to MoreMasters, then bang the heck out of your program, doing just about everything as much as it can be done. Then use MacsBug or TMON to view the heap and count blocks of size $108, as well as $10c and $110. These are the master pointer blocks. Call MoreMasters that many times plus 20% at the start of your program. 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." Tech Note #53 is from my birthday (Oct 28) in 1985; no such tech note has appeared yet, more than two years later. Perhaps in time for the first 68,000,000-based Mac.... -- Tim Maroney, {ihnp4,sun,well,ptsfa,lll-crg}!hoptoad!tim (uucp) hoptoad!tim@lll-crg (arpa)
stew@endor.harvard.edu (Stew Rubenstein) (12/10/87)
In article <1987Dec7.094745.599@mntgfx.mentor.com> tomc@mntgfx.mentor.com (Tom Carstensen) writes: >What is a good guideline as to how many times you should >call MoreMasters? I've seen some programs call it >about 10 times, others 7 - is there better documentation >on the ROM call then that of Inside Mac? You gotta figure out how many handles your application is likely to need. My stuff has a varying requirement depending on how big the documents that the user works with. What I do is call it once for every 64K of memory allocated to the application heap. If the user resizes my app so that s/he can handle bigger documents, I therefore allocate more handles. The other way is simple trial and error - run your app for a while and then look at the heap with TMON or Macsbug or whatever. See how many master pointer blocks (0x100 byte nonrel blocks near the bottom of the heap) there are in your heap. Call MoreMasters that many (minus one) times in your startup code. Stew Rubenstein Cambridge Scientific Computing, Inc. UUCPnet: seismo!harvard!rubenstein CompuServe: 76525,421 Internet: rubenstein@harvard.harvard.edu MCIMail: CSC
lsr@apple.UUCP (Larry Rosenstein) (12/11/87)
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
schmidt@lsrhs.UUCP (Chris Schmidt) (12/11/87)
In article <4805@cit-vax.Caltech.Edu> sho@tybalt.caltech.edu.UUCP (Sho Kuwamoto) writes: >In article <1987Dec7.094745.599@mntgfx.mentor.com> tomc@mntgfx.mentor.com (Tom Carstensen) writes: >>What is a good guideline as to how many times you should >>call MoreMasters? I've seen some programs call it >>about 10 times, others 7 - is there better documentation >>on the ROM call then that of Inside Mac? >> > You should think about getting a good debugger like TMON. If you Definitely check the heap with a debugger -- if you need to have specific control over your program's use of the heap. But is there a specific reason why you're not calling MaxApplZone() and letting it take care of bidness? -- ------------------------------------------------------------------------ Chris Schmidt/Lincoln-Sudbury High School/390 Lincoln Rd/Sudbury/Ma/01776 (617) 926-3242 -----> mit-caf!lsrhs!schmidt@eddie.mit.edu