Do modern operating systems use memory control blocks?

Question

I was taught in my operating systems class that sections of memory in the heap are marked as free/occupied through the use of memory control blocks (MCB). The generalized definition of an MCB that was given to us is that they hold two memory addresses (one for the next MCB and one for the previous MCB), the size of the block of memory attached to the MCB, and a flag stating whether that block is occupied or not.

When a chunk of memory is requested, the OS finds an unoccupied MCB, marks it as occupied, and creates a new MCB at the end of the now occupied block.

This seems like a sensible way to do things, and yet I cannot find any mention of the term "memory control block" outside of explanations of how DOS tracks memory allocations, even in the textbook Operating Systems Concepts (Silberschatz et al).

I'm confident that some sort of administration is going on, via a simple C++ program that creates several pointers to ints and then prints out the addresses stored by the pointers, which are consistently not consecutive (although I guess this doesn't prove anything for sure).

What's going on behind the scenes? Are MCBs simply called something else nowadays?

Answer 1

This is really a question about memory allocators and doesn't have much to do with operating systems. "Memory control block" does seem to be a DOS specific term for a node in a free list. I'm not aware of any broadly used term for those nodes. They are usually just called "free blocks" or "unallocated blocks" or some such.

An operating system kernel usually has memory management concerns of its own. A popular choice for Unix-like systems is slab allocation. In Linux, there's a variation that is possibly the default nowadays called SLUB, and there is another option called SLOB which stands for "simple list of blocks" which does correspond to a free list approach.

At the lowest levels though, most popular, general-purpose CPUs organize allocation of physical memory with a page table. (More accurately, page tables manage the physical to virtual address mapping.) The kernel still must keep track of which pages of physical memory are allocated and to which process, but the page table structure makes this a bit less flexible. The main point being that pages come in fixed sizes which allows memory allocation techniques built on fixed sized blocks. In particular, according to Wikipedia, Linux uses a zoned buddy allocator.

So the overall picture looks like this: at the lowest level you have an allocator to keep track of physical pages of memory; above that you have an arena-like allocator motivated by the fact that you often want to allocate many smaller-than-a-page objects and you obviously don't want to allocate a page to each; above that a programming language runtime may have its own memory allocator that may exploit details of the programming language to perform better; finally, an application may do some memory allocation of its own, often also using arenas but now usually motivated by time-cost issues like the costs of allocating/deallocating and data locality.