Date: Tue, 16 Nov 1999 09:27:02 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Rafael García <rafael AT geninfor DOT com>
cc: djgpp AT delorie DOT com
Subject: Re: heap fragmentation
In-Reply-To: <80ph6k$t7v$1@lola.ctv.es>
Message-ID: <Pine.SUN.3.91.991116092646.6671G-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by delorie.com id CAA23424
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Mon, 15 Nov 1999, Rafael García wrote:

> text[nline]=malloc(width);
> ...
> strcpy(text[nline],buf);
> nline++;
> ...
> 
> 
> during load, there may be some line that don't fix in the prepared width so
> after reading all the file I need to start over changing to the extended
> width (all lines must have max width), so I free all lines:
> 
> for (n=0;n<nlines;n++) free(text[n]);

This seems like a terribly inefficient way of using memory.

One way of making it better would be to allocate the entire memory as
one large chunk (number of lines multiplied by the line length), and
then realloc it as needed.  Then you won't need to worry about
fragmentation.

Also, you don't explain why do you need each line be of the same
size.  I seriously doubt that this is required; perhaps a slightly
different design would remove the problem altogether.

> My question is:  is there any method to 'pack'/'unfragment' the heap so I
> can know the really amount of used memory?

No.  The DPMI environment doesn't have any way of knowing where in the
address space will the DPMI server alloocate any given chunk of
memory.  So you are totally at the mercy of the DPMI server and the
numbers it reports when you call _go32_dpmi_remaining_physical_memory.