🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: borland.public.cppbuilder.nativeapi
Article #9188

Re: Problem with memory again

#9188
From: Andrue Cope [TeamB]
Date: Fri, 23 Jul 2004 08:17
46 lines
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-mail
References: <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