tomc@mntgfx.mentor.com (Tom Carstensen) (02/07/89)
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 had 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 you could send be a little more info on this scheme. Thanks Tom Carstensen
lsr@Apple.COM (Larry Rosenstein) (02/08/89)
In article <1989Feb6.142037.2211@mntgfx.mentor.com> tomc@mntgfx.mentor.com (Tom Carstensen) writes: > >I read about a scheme you had 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. The basic scheme divides memory requests in to permanent and temporary. Permanent request are those associated with the application's data; they're permanent because you can only get that memory back if there user deletes the data. Permanent requests can fail, resulting in a message to the user. Temporary requests involve things like loading segments, defprocs, packages, etc. They're temporary because once the particular operation is finished, the memory will be freed (eg, the segment will be unloaded). Temporary requests must always succeed, otherwise the system will bomb. Normally, allocated memory is considered temporary. There is a call to switch into permanent mode, in which case allocations are considered permanent. The only difference between the 2 modes is in the behavior of the grow zone proc. In MacApp, the programmer specifies the maximum amount of temporary memory that will be allocated at any point. You do this in a series of resources. Some resources can specify a number, and others the names of code segments that form the maximum code working set. We maintain 2 reserve handles. The first is used to guarantee that the max temporary memory is available. The second is used as a reserve against permanent requests. In order to get the best utilization of memory, you want to subtract from the temp reserve handle the size of the code segments, defprocs, etc. that are already in memory. It is not necessary to do this continuously. If you think about it, the only important time is when you are allocating some permanent memory. What you don't want to do is allow the permanent request to succeed, but leave you with an insufficient temporary reserve to satisfy the maximum temporary usage. So when the programmers switches to permanent mode, MacApp ensures that the required temporary reserve is available. This involves adding up the sizes of the loaded code segments, defprocs, etc. and subtracting it from the size needed. If the result is > 0 we allocate a reserve handle of that size. In the grow zone, if the temporary/permanent flag is on temporary, then the grow zone proc will immediately free the temporary reserve handle, to try to satisfy the request. If it is on permanent, then it is more careful about what memory it releases. That's the basic idea. There are some subtleties in the grow zone proc and because you have to be careful that the Memory Manager is not trying to move one of the reserve handles. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr