Date: Wed, 14 Jul 93 09:40:28 EDT
From: DJ Delorie <dj AT ctron DOT com>
To: jweiss AT silver DOT sdsmt DOT edu
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: memory problems


Implementing coreleft() for go32 is a popular request, as is a better
malloc package (don't recommend gnu - I can't use GPL in libc.a).  I'm
hoping to implement a lot of _go32_XXX() functions, like
_go32_realmemleft() and _go32_virtmemleft(), that will help solve a
lot of these problems.

> Turbo C outputs "1032 bytes were just allocated" - the 8 extra bytes are
> obviously malloc bookkeeping overhead. However, with DJGPP the output
> is "4096 bytes were just allocated"! I don't think it's simply a power
> of 2, since 4096 sounds suspiciously like a page size - have to take a
> look at the code for malloc sometime....

Most Unix malloc()'s will always bump sbrk() in page increments, since
that is the unit of allocation that the kernel uses anyway.  DJGPP is
no exception - go32 deals with pages (4k), not bytes, so malloc always
rounds sbrk() up to a page boundary.  The 2^N overhead can be seen
with a much larger allocation, say 33K, where sbrk() will be bumped to
64K.