lsr@Apple.COM (Larry Rosenstein) (03/30/88)
In article <4260@husc6.harvard.edu> stew@endor.UUCP (Stew Rubenstein) writes: > >toolbox needs the memory for. You have to assume that any request is >critical. This is not far from the truth - memory allocation failures >are handled very poorly by the toolbox. In my apps, I have routines >Critical() and NonCritical(), which clear and set a flag checked by In MacApp we do a similar thing, except critical requests are called "temporary", and non-critical requests "permanent". This reflects whether or not the memory is for the user's document, and cannot be reclaimed later. Temporary (critical) memory consists of code segments, defproc resources, packages, etc. By default all requests are temporary (ie, critical), although the programmer can change the state of the flag as needed. We also provide a call NewPermHandle to allocate a permanent handle. >allocations in my own code. Another useful trick is to allocate a >couple of buffers at the start of your program so that you have >something to release when the growzone proc is called. In MacApp, the programmer can specify the size of the temporary and permanent reserves. The permanent reserve is just a last chance piece of memory that the grow zone proc will release if all else fails. When this memory is gone, then memory is really low and MacApp will put up a message telling the user this (overridable of course). The size of this reserve is usually only 4-10K. The temporary reserve is more interesting. The programmer sets this size based on the maximum amount of temporary memory the program will need at any time. MacApp will ensure that this amount of memory is available. We add up the currently loaded segments, defprocs, etc.; if the sum is less than the reserve we allocate a handle to make up the difference. (This is so memory is not wasted trying to maintain the reserve.) If the programmers sets the temporary reserve correctly, then the program cannot bomb because a code segment, package, etc. cannot be loaded. >Finally, it's important to preflight every memory request that you >can. For example, before you call a routine in another segment, do a >GetResource on the right CODE segment and check to see it succeeds. A >failure to load a CODE segment causes an immediate system error. The This approach will work, but it makes it difficult to change the program's segmentation without having to change the code. Also, in the case of MacApp, we could not know how the final program would be segmented, since we can't know what code the developer will be writing. In MacApp, you specify the name of the segments that form the maximum code working set, as well as an absolute number to add in. This information is in resources so that it can be changed easily. (The MacApp debugger helps you determine which segments comprise the maximum working set.) The idea here is that the maximum working set might change in value, but the segments that make up the working set should be consistent. The programmer can also change the size of these reserves programmatically. The only kind of preflighting we do in MacApp is when opening a DA. We make sure that there is enough permanent memory for the DRVR resource, and then we open the desk accessory with the temporary flag on. This helps ensure that the DA won't bomb when opening (in case it doesn't check its memory allocations). After the DA is opened, we check to see if our guaranteed temporary reserve has been exhausted. If so, then we immediately close the DA and report an error. (This assumes that the DA cleans up after itself, but there is nothing an application can do with such unfriendly DAs.) Region operations that occur in the normal course of events (invalidating a window) are considered temporary, and the temporary reserve should handle them. This would only be a problem if regions were being used at the time when the maximum code working set was loaded. MacApp also unloads all code segments each time through the event loop, although the programmer can mark a segment as resident and then it won't be unloaded. Unloaded segments stay in memory in case they are needed again. This memory management architecture seems to work very well. It has the advantage that it is generic, and doesn't have to recoded for each application. The programmer only has to plug in the specific parameters of the application. Before MacApp was released, we tested our memory management by having the testing group stress test one of our sample programs as if it was a product. -- 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
tomc.build@mntgfx.mentor.com (Tom Carstensen) (01/21/89)
I while ago there were a few articles about memory management
schemes. I trying to get more info about the following
scheme:
I'm trying to get my memory management staightened out. I
have re-segmented my program, made sure that every call
to a memory allocation routine checks for an error, put in a
Grow proc and have allocatyed a small buffer when all attempts
to allocate memory fail. Everything is working great, the
only problems I have are system errors when a code segment
that is needed can't be loaded into memory.
I read about a scheme you for MacApp, where you determine the
maximum code set, and make sure there is at least this much
memory minus the memory currently used by loaded code segments.
Question: Do you add up the total memory used by loaded
code segments continuously, - I guess I'm not quite sure how
this scheme works.
I would appreciate it if anyone could send me a little more info
on this scheme.
Thanks
:------------------------------------------------------------:
: | GEnie: T.CARSTENSEN :
: Thomas Carstensen | Delphi: CARSTENSEN :
: Mentor Graphics | CompuServe: 73627,2762 :
: 8500 SW Creekside Pl. | :
: Beaverton, OR 97005-7191 | tomc@pdx.MENTOR.COM :
: (503) 626-7000 | ...{sequent,tessi,attunix, :
: | apollo}!mntgfx!tomc :
:------------------------------------------------------------:
: . . . This is Edison Carter coming to you very much :
: live and direct from Network 23 . . . :
: - Edison Carter :
:------------------------------------------------------------:wwg2101@venus.tamu.edu (GILPIN, WESLEY WILSON) (10/25/90)
I need some help programming in Turbo Pascal 1.1. I have a program that I would like to make compatible with my after dark screensaver, but every timethe screensaver comes on it gives an out of memory message. Is there something that I can do to free up the memory that isn't being used by my program? Reply by E-Mail please