Article View: borland.public.cppbuilder.nativeapi
Article #9188Re: Problem with memory again
From: Andrue Cope [TeamB]
Date: Fri, 23 Jul 2004 08:17
Date: Fri, 23 Jul 2004 08:17
46 lines
3086 bytes
3086 bytes
Sara T. wrote: > Why? is that OK and normal? Yes, very normal. When you minimise an application Windows trims its working set (the amount of RAM actually being used) and this is what causes the drop. This behaviour is typical of an application that has allocated a lot of memory (or has a lot of code) but is not using much of it (or infrequently). With large amounts of memory not being used Windows is able to remove it from RAM and leave it in the swap file to be brought back in as needed. However:This behaviour is also an indication of a possible issue with the Borland Heap Manager. Under certain conditions (typically large numbers of allocations and deallocations of both large and very small blocks) you will see increasing memory usage even though a memory testing tool indicates no leakage and your code should not be needing increasing amounts of memory. There is still debate as to whether this is an issue or not but several people have seen it including me. You may or may not know that the HM allocates memory from the OS in large chunks and then subdivides this into the actual chunks you ask for. This means that when you deallocate a small block of memory it doesn't get returned to the OS. Instead the HM notes it and will recycle it later if possible. What /appears/ to be happening is that certain patterns of allocation/deallocation result in the Heap Manager losing track of free space blocks. My own theory is that the HM has a self-imposed limit on the number of free blocks it will track (for performance reasons possibly) and that if you free too many they start to be lost permanently (until the app. closes anyway). The solution we have adopted in both the cases we saw it was to write our own 'memory block cacher'. It's a very simple class through which certain allocations/deallocations are performed. It still uses the HM but acts as a first line of defense in helping recycle unused memory. I'm going to have a play with this today and see if I can produce a test case. I've never managed before but I like a challenge :) -- Andrue Cope [TeamB] [Bicester, Uk] http://info.borland.com/newsgroups/guide.html
Technical Details
Message-ID:
<4100c97e@newsgroups.borland.com>Path:
arc1-ca.pugleaf.net!g2news1.google.com!news2.google.com!proxad.net!proxad.net!194.159.246.34.MISMATCH!peer-uk.news.demon.net!kibo.news.demon.net!demon!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsgroups.borland.com!not-for-mailReferences:
<4100b152@newsgroups.borland.com>Show Full Headers
Complete Article Headers
X-Google-Thread: 10cc67,e9f11b4f112d3007 X-Google-Attributes: gid10cc67,public X-Google-Language: ENGLISH,ASCII-7-bit From: "Andrue Cope [TeamB]" <no.spam@spammy.com> Subject: Re: Problem with memory again Newsgroups: borland.public.cppbuilder.nativeapi References: <4100b152@newsgroups.borland.com> User-Agent: XanaNews/1.16.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 NNTP-Posting-Host: 217.207.223.34 Message-ID: <4100c97e@newsgroups.borland.com> Date: 23 Jul 2004 01:17:02 -0700 X-Trace: newsgroups.borland.com 1090570622 217.207.223.34 (23 Jul 2004 01:17:02 -0700) Lines: 46 X-Authenticated-User: acope Path: arc1-ca.pugleaf.net!g2news1.google.com!news2.google.com!proxad.net!proxad.net!194.159.246.34.MISMATCH!peer-uk.news.demon.net!kibo.news.demon.net!demon!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsgroups.borland.com!not-for-mail