Mail Archives: djgpp/1994/11/08/01:23:38
> (1) The EMS memory is what go32 is using, which is why you start with
> only 4M and not 16M.
> (2) When you call malloc, that doesn't actually *use* memory. It just
> *reserves* it. You could malloc 100Mb and not use it, and still have
> most of your physical memory available. If you want to *use* the
> memory, call memset() to fill it with zeros or something.
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.
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.
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.
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.
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.
Xanthian.
--
Kent, the man from xanth.
Kent Paul Dolan, CSC contractor at Fleet Numerical. (408) 656-4363.
(Navy Unix email: ) (Navy cc:Mail email: ) (real world email: )
<dolan AT fnoc DOT navy DOT mil> <dolank AT fnoc DOT navy DOT mil> <xanthian AT well DOT sf DOT ca DOT us>
- Raw text -