Mail Archives: djgpp/1994/05/10/10:17:50
Henrik Storner writes in response to David Ronis:
>
>David Ronis writes:
>
>> I use djgpp under Desqview/X. For the most part, I use it when I need to
>> access large arrays. Thinks work correctly, but I've noticed that malloc
>> allocates system memory irreversibly; for example, free doesn't seem to return
>> the memory to the system (DV/X) until the program exits, or if I have a large
>> local array in a function, this memory is not returned to the system when
>> the program exits.
[Example deleted]
>It is true, that the EMS memory allocated by go32 doesn't get freed until
>the program terminates - I guess this is just the way that go32 handles
>memory allocation: Once it has got some memory, it hangs on to it until
>it terminates - free and malloc then use whatever memory is already
>allocated, or allocate more if needed.
malloc() and free() are working as they do under Unix. The only call that
really allocates memory (in the sense of expanding your legal address
space, and requesting more of it from the system) is sbrk(). malloc() and
free() manage a heap which is expanded when necessary using sbrk().
sbrk() under Unix systems is a one-way operation ; you can get bigger,
but you can't get smaller. This is frustrating for some long-running
applications that need large amounts of memory for a short time,
but that's the way it is. For djgpp, sbrk() is actually using (I presume)
DPMI services or whatever is out there to manage the memory,
if anything. These probably do let you give memory back as well as asking
for it, but malloc() is doing things via sbrk() which doesn't
have any way to return the memory.
>I don't know how much work it would take to alter go32 so that it would
>really free up whatever memory was freed - my guess is that it might be
>non-trivial, as the free() algorithm would also have to take care of the
>freed space not necessarily being contiguous. Thus, freeing up the EMS memory
>would require shuffling other parts of allocated memory around, and then
>keeping track of what points to that memory.
It's not just non-trivial, it's impossible if you think about it. malloc()
has no way of knowing what its caller does with the pointer it returns - it
could even write it to a file which it reads later in the program if
it wanted to be perverse. It is never permissible to move around malloc'ed
blocks once they have been allocated. The only thing you could hope to do is
to free memory at the end of your address space when possible, or chunks in
the middle if they are on memory allocation boundaries and the memory
allocation system (I'm speaking generally here, not just about DOS)
lets you do that.
------------------------------------------------------------------------------
Kevin Ashley K DOT Ashley AT Ulcc DOT ac DOT uk
Systems Development Group Manager ...ukc!ncdlab!K.Ashley
University of London Computer Centre.
- Raw text -