malloc/free don'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?
Q: I malloc'ed a large chunk of memory, but when I check
values returned by _go32_remaining_physical_memory or
__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
available RAM....
Q: I'm looking for a way to tell how much memory is available,
something like 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 calloc and
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 sbrk(0);.
Alternatively, disabling virtual memory altogether (by using CWSDPR0 or
by loading CWSDPMI with -s- parameter), and checking values
returned by malloc against 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.