Mail Archives: djgpp/1994/11/08/02:52:02
> That's beating up on the English language pretty hard. Malloc() uses
> memory in the sense that if you malloc() until you have malloc()ed more
> than the allowable total of physical + virtual, you should get back a
> failure in any reasonable memory management system implementation.
malloc will not let you reserve more memory than you have physical RAM
and disk space to honor such a reservation. The key factor here is
DISK space. The function that originated this thread,
_go32_dpmi_remaining_physical_memory, returns the amount of RAM that
is not currently mapped into the existing process, and thus is
available for immediate mapping without needing to page something else
out to disk.
> Notice "should", not "will". Back in "the good old days" of a 32 bit
> virtual address space and buddy system memory management, that at least
> meant that malloc() should return null once you've burned up the 2*32
> bytes of the address space.
Malloc will fail if it cannot reserve enough virtual memory.
> The problem seems to be that the "memory meter" is measuring in terms
> of virtual memory pages, and with a lazy paging system, the usual case,
> a page isn't expended until it is read or written. That doesn't mean
> that it is _unused_, merely that it is _untouched_, not the same
> thing. The name and semantics of the ...physical_memory_remaining...
> or whatever seem to be in conflict.
From go32's point of view, the page is unused. Go32 has not even
allocated it (in most cases, it hasn't even asked the system for it)
and has not written anything to it. In fact, it doesn't even know its
address until it's time to write to it and it goes and gets one from
the free page store.
In fact, if you call system(), some memory gets paged out, and you
then have more physical memory available, since the free store has
more pages now.
> At the point that malloc() responds with null, your "memory meter"
> is BROKEN if it still shows enough memory left to satisfy the malloc()
> request, leaving out the question of contiguity of that remaining
> memory for the moment.
The function YOU want is _go32_dpmi_remaining_virtual_memory(), which
is how much you can expect to malloc(). This does not guarantee that
paging will not ensue when you access that memory.
> Probably free physical pages * page size, or whatever is happening to
> give this result, was the wrong answer to return to the question "how
> much memory do I have left", since the answer turns out not to be
> useful.
The original question was "how much memory can I malloc() and use
without degrading performance by paging". The function
_go32_dpmi_remaining_physical_memory() answers that question.
- Raw text -