Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!samsung!uunet!pcad!rob From: rob@pcad.UUCP (Ralph Brown) Newsgroups: comp.windows.ms.programmer Subject: Re: Allocating a lot of memory (why can't I?) Message-ID: <524@pcad.UUCP> Date: 23 May 91 14:32:30 GMT References: <518@pcad.UUCP> <72462@microsoft.UUCP> Organization: Personal CAD Systems, Westford, MA Lines: 47 In article <72462@microsoft.UUCP>, donc@microsoft.UUCP (Don CORBITT) writes: > In article <522@pcad.UUCP> rob@pcad.UUCP (Ralph Brown) writes: > >In article <72271@microsoft.UUCP>, donc@microsoft.UUCP (Don CORBITT) writes: > [donc makes suggestions] > >> I'm able to routinely allocate 4 MB (and sometimes 8MB) on my system with > >> 8MB ram, (6MB available to Windows). You should be able to, also. > [(Ralph) supplies details, which include oscillation 1.x MB to 3.x MB]> > donc makes more suggestions: > This was a fun question, so I looked into it further. PageLocked (uncommon) > and Fixed (too common!) objects fragment the protect-mode heap. If you > had ToolHelp.DLL, you could scan the heap in your program, and find which > if any memory blocks are fixed or pagelocked. This would let us know if > there was a believable explanation for this behaviour. > > Answering your question, I ran a quick, 10 line program (output was a > MessageBox() :-), so I don't know why I got 4MB some times, and 8MB others. > However, the granularity was 2X each request, so it may be that 7.999MB was > available when I say I only got 4MB. You may have missed a later posting I (ralph) made. It seems that if you sneak up on a big allocation you can get much more than just asking for it. I wrote a small (50 line) program that output to the window title to keep the heap as simple as possible which kept asking for larger chunks, then freeing them. If it got a refusal, it went back to the last one that worked and cut the size of the next increase in half. If it succeeds it just frees the memory, adds the same increment and tries again. What happens is that the first time it runs in an instance it hits a temporary barrier where an allocation of 2MB fails, then it cuts the increment down to 1953 bytes in several steps and from then on increasing size requests succeed up to about 3.2 MB at which time it binary searches to about 3.1 MB. If this is then run again in the same instance with the starting point at 1MB and the starting increment at 1MB (same as the first time) it gets 3MB, fails at 4MB and settles rapidly on 3.1 MB. It seems like there is some sort of heap conditioning going on. Could this be related to GlobalCompact not dealing with virtual memory? The max size I can get (3.1MB) seems to not be a function of my virtual memory size. If I increase the swap file a lot (from 4MB to 16 MB with 4MB RAM), there is no increase in the max mem size. This seems to be all I can allocate in all processes also. If I get the 3.1MB I cannot start anything else although I have over 10MB and 70% of resources free. No, I don't have TOOLS.DLL, nor for that matter have I ever heard of it, did part of my SDK get mangled :->. Ralph