What happens behind the scene (and by whom) when heap memory is deallocated?

[ElusiveTau]

A couple of what's-under-the-hood questions floating in my mind, having to do with freeing memory:

1. How does a program know what part of its virtual address space, allocated for heap memory by the linker script, has or hasn't been used?

2. What happens when heap memory is deallocated? Does the processor expend some clock cycles to execute system code to "free up" heap memory (e.g., maybe mark used heap region as unused so it can be reused) and if so, is this done transparently (without the application knowing it)?

[JLBorges]

K&R (The C Programming Language, second edition) has an example of a rudimentary storage allocator (Section 8.7). This would give us the general idea.

malloc will request space from the operating system as needed. Since other activities in the program may also request space without calling this allocator, the space that malloc manages may not be contiguous. Thus its free storage is kept as a list of free blocks. Each block contains a size, a pointer to the next block, and the space itself.

[salem c]

1. Where things go in VM is decided by the OS, not the linker.
https://en.wikipedia.org/wiki/Address_space_layout_randomization

> 2. What happens when heap memory is deallocated?
The run-time library linked in with each program manages a memory pool that is within the address space of the program. This keeps most of your alloc/free calls cheap as it doesn't involve the OS.

But if you do run out of memory in the local pool, the program run-time will ask the OS for more memory (usually more than you actually wanted). Asking the OS is expensive, so the local allocator tries to minimise OS level calls as much as possible.