Memory Management Problem: Records (of various lengths) need to be stored. Model: A big array of space to store them, managed by a memory manager. Like a coat-check stand, give them your coat, get back a ticket. Later, return the ticket for your coat. We call the ticket a handle.

Memory Manager ADT // Memory Manager abstract class class MemManager { public: // Store a record and return a handle to it virtual MemHandle insert(void* space, int length) =0; // Release the space associated with a record virtual void release(MemHandle h) =0; // Get back a copy of a stored record virtual int get(void* space, MemHandle h) =0; };

Implementation Issues The client doesn’t know what is in the ticket. The memory manager doesn’t know what is in the message. Multiple clients can share a memory manager. The memory manager might interact with a buffer pool: –The client decides what gets stored –The memory manager decides where things get stored –The buffer pool decides when blocks are in main memory

Dynamic Storage Allocation Use a memory manager when: –Access patterns are uncertain –Messages are of varying length Over time, memory contains interspersed free blocks and reserved blocks. –When adding a new message, find a free block large enough –When deleting, merge free blocks

Fragmentation Internal fragmentation: when more space is allocated than the message size. –Might be done to make memory management easier –Example: Sectors and clusters on disk External fragmentation: Free blocks too small to be useful.

Managing the Free Blocks A key issue is how to merge free blocks 1)Use a linked list of free blocks (external to the memory pool) 2)Add tags to the ends of the free and reserved blocks (part of memory pool)

Selecting a Free Block Somehow, need to pick one of the free blocks in which to store the message It must be at least as large as the message (plus whatever info the memory manager needs, such as size and tags) Extra space can be returned as a free block Want to minimize fragmentation, and avoid failing to service requests

Sequential Fit Methods First Fit: Start from beginning, pick first free block that is big enough –Store list in memory-pool order –Circular first fit: Move forward from current position Best Fit: Pick the smallest block big enough –Store by block size, or search list –Protect large blocks for big requests Worst Fit: Pick the biggest block –Store by block size, or search list –Avoid external fragmentation

Failure Policies What do we do if there is no free block that can hold the message? Must resort to a failure policy. Reject the request Grow the memory Compact the memory Garbage collection