Is releasing memory pages by a process possible in principle?

Question

Disclaimer: I do have a diploma in CS but this topic was never explicitly explained to me. I am just stiching pieces of what I know into a whole. Please correct me if I get something wrong.

Suppose you have a C program: you call malloc(1MB). This function does not allocate any memory pages from the OS. All it does is allocate a range of addresses from virtual memory address space using a heap. Those addresses are not mapped onto any real memory pages yet. At first write into the address, the CPU catches an exception (or interrupt or something) and assigns a new memory page to that address and then the write follows successfully.

Then I call the free() function. This function also does not release any memory pages back to the OS. All it does is put the address range back into the heap for future reuse.

My point is that memory pages are never released (until process termination). Is that right? There is no syscall for releasing memory pages, is there? And the OS itself cant guess which pages are not used anymore. All it can do is look which pages are Least Recently Used and move those to swap.

Related (somewhat) question: Is forcing an application to release some the allocated memory possible? Also related: https://stackoverflow.com/questions/1421491/does-calling-free-or-delete-ever-release-memory-back-to-the-system

Answer 1

Releasing pages is possible in principle and in practice.

malloc and free don’t necessarily result in reserved address space; they can be implemented using mmap and munmap, in which case the corresponding address space and any populated pages can both be returned to the kernel after munmap. It’s also possible for processes to reduce their allocated address space with sbrk.

The madvise function can also be used to discard pages, without releasing the address space.

Answer 2

In the end, it is up to the operating system kernel if it allows "giving back" (virtual memory) pages piecemeal (it might be a mess to do so; and not that relevant in practice, a page that isn't used will soon enough get evicted from RAM anyway). For more or less the same reasons, the language's runtime may just keep stuff around (if you e.g. in C go malloc() and free(), nothing guarantees your freed space is a contiguous page in the address space -- giving it back just to have to ask for more space later on has it's cost).

Unix has sbrk(2), which allows to expand/contract the data segment of the process, but that assumes there is one data segment (you might end up with several), the runtime stack in principle expands and contracts. Again, if the language's runtime or the kernel acts on this is up to the implementation.

Check e.g. C's standard: They carefully word their "as if" rule, the program has to behave in a way explainable by abstracting away any such details and handling of any resource limits.