Date: Tue, 21 Apr 1998 13:11:43 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc: dj AT delorie DOT com, nate AT cartsys DOT com, djgpp-workers AT delorie DOT com
Subject: Re: Available memory
In-Reply-To: <9804201318.AA13645@clio.rice.edu>
Message-ID: <Pine.SUN.3.91.980421131116.1009A-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Mon, 20 Apr 1998, Charles Sandmann wrote:

> But the free blocks internally managed by malloc() are in size bins, so if
> the user wants a big single allocation that memory is essentially not free.

True, but `coreleft' is a compatibility function.  Borland documents
it thusly:

   In the small data models, `coreleft' returns the amount of unused
   memory between the top of the heap and the stack.  In the large
   data models, `coreleft' returns the amount of memory between the
   highest allocated block and the end of available memory.

So it seems like even making `coreleft' an alias for
`_go32_dpmi_remaining_{virtual,physical}_memory' (I vote for physical)
would be enough.  If we add to that some measure of what's on the free
list, it would be even nicer.

> If you are going to mess with it, then it ought to be something like the
> non-sbrked available virtual memory, rounded down to the nearest power of
> two (or whatever the current malloc does in that case).

I can live with that.  From my experience, many people who use this
function in Borland don't really understand the memory issues anyway.