UNIX vs Windows memory deallocation

There isn't much difference between Windows and Unix with respect to that.

In both, there are two levels of allocation. The operating system allocates memory to the process in large chunks (one page or more; on x86, the page size is usually 4096 bytes). The runtime libraries, running within the process, subdivide this space and allocate parts of it to your code.

To return the memory to the operating system, first all the memory allocated from one of these large chunks has to be released to the runtime library. The runtime library then can, if it wants, tell the operating system to release that chunk of memory.

On Linux, you have brk and mmap. brk controls the size of of a large chunk of memory allocated to your process; you can expand or shrink it, but only at one end. malloc traditionally expands this chunk of memory when it needs more memory to allocate from, and shrinks it when possible. However, shrinking is not easy; it takes a single one-byte ill-timed allocation at the end to make it unable to shrink even if everything before that allocation has been freed. This is the source of the "Unix doesn't release memory back" meme.

However, there's also anonymous mmap. Anonymous mmap requests a chunk of memory from the operating system, which can be placed anywhere in the process memory space. This chunk can be returned easily when it's not needed anymore, even if there are later allocations which weren't released yet. malloc uses also mmap (particularly for large allocations, where a whole chunk of memory can be easily returned after being freed).

Of course, on both Windows and Linux if you do not like the behavior of the memory allocator (or allocators) from the runtime libraries, you can use your own, asking memory from the operating system and subdividing it the way you want (or sometimes asking memory from another allocator, but in larger blocks). One interesting use is to have an allocator for all the memory associated with a task (for instance, a web server request), which is completely discarded at the end of the task (with no need to free all the pieces individually); another interesting use is an allocator for fixed-size objects (for instance, five-byte objects), which avoids memory fragmentation.

Note that I know much more about Windows than Unix in what follows ...

What actually happens with memory allocation and deallocation isn't quite what you describe, in any case. This is because there's two very different concepts at work here: the physical memory that the computer possesses, and the virtual address space of the program, the memory that your program thinks it can use.

When your program requests more memory from the operating system, what is really happening is that previously unavailable virtual address space in your program is being set up as accessible by the program. Modern operating systems don't work by just having a pool of "real" (that is, physical) memory that it hands out to processes when they make an allocation request: it maintains the virtual address space for every running program, and, when programs actually access parts of that virtual address space, ensures that this is mapped to some physical memory, possibly by swapping out some part of another program's address space to the swap file on disk.

As an example of this, on Windows each thread starts with (by default) a megabyte of stack space allocated for it. This doesn't mean that every thread consumes a megabyte of the machine's physical memory: it is simply that the address space is set up so that it is available for use. In this sense it doesn't really work to think about the operating system giving your program memory and then the program giving it back - it just doesn't work like that.

It all depends on which C runtime library you use. There is NO specific UNIX way or WINDOWS way. Each compiler vendor(HP, SUN, MS, GNU) ships with their own runtime library that contains the logic for malloc. each implementation of malloc will operate same/different depending on the OS. Neither UNIX/LINUX/Windows needs that a free "ACTUALLY RETURN" the memory back to the OS. That would be too expensive (since your alloc() would be in very small chunks)

Recently mozilla Firefox borrowed a malloc() implementation from *BSD OS. They chose to use a different malloc than what their compiler vendor (multiple in this case -- gcc and VC++) shipped. Since they wanted a certain behavior, they got what they wanted.