[an error occurred while processing this directive] Node:Confusing alloc, Next:, Previous:How much memory, Up:Memory

15.2 It seems 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.

[an error occurred while processing this directive]