Previous:How much memory,
freedon't affect virtual memory...
Q: I did
malloc(50*1024*1024), but didn't see any paging
happen, and I only have 8 MBytes of RAM on my machine. Is this virtual
memory thing for real?
malloc'ed a large chunk of memory, but when I check
values returned by
__dpmi_get_memory_information, I don't see any change!
Q: When I
free allocated RAM,
_go32_remaining_physical_memory reports there was no change in the
Q: I'm looking for a way to tell how much memory is available,
coreleft in Borland C?
A: CWSDPMI (and, possibly, other DPMI hosts) only pages in memory
when it is actually accessed. If you only
malloc it, but don't
actually access it, it won't grab those pages. Try
see the big difference.
When you call
free, DJGPP library doesn't return memory to the
system, it just adds it to its internal pool of free pages. So, from the
point of view of the DPMI server, these pages are not "free".
In addition, several widely-used DPMI servers, such as those built into
Windows, have their own quirks related to memory allocation. For
example, some of them won't let you allocate more than half the
available memory in a single chunk. As another example, on OS/2
_go32_remaining_physical_memory reports a constant very large
value that doesn't change in the course of the program.
Note that the distinction between the physical and virtual memory is only meaningful on DOS. More sophisticated operating systems usually conceal the difference entirely, so only the sum of these two types of memory usually (but not always) gives an approximation of the total free memory.
Because of these peculiarities, there's no convenient and easy way to
return the amount of free memory available at any given moment, even in
plain DOS. Some programs only care about available physical RAM (they
don't want to page to disk, since that causes a considerable slow-down);
for these, I recommend to call the
_go32_remaining_physical_memory library function at program
startup, and then track memory usage with
Alternatively, disabling virtual memory altogether (by using CWSDPR0 or
by loading CWSDPMI with
-s- parameter), and checking values
NULL, might be all you need to
know when you are about to run out of free physical memory. Programs
that need to know when they are about to run out of virtual
memory should call
_go32_remaining_virtual_memory instead. Once
again, these methods will only work reasonably well in plain DOS.