Memory ManagementFive Requirements for Memory Management to satisfy:RelocationUsers generally dont know where they will be placed in main memoryMay want to swap in at a different placeMust deal with user pointersGenerally handled by hardwareProtectionPrevent processes from interfering with the O.S. or other processesOften integrated with relocationSharingAllow processes to share data/programsLogical OrganizationSupport modules, shared subroutinesPhysical OrganizationManage mem disk transfers

Techniques Table 7.1, page 306Fixed PartitioningDivide memory into partitions at boot time, partition sizes dont changeSimple but has internal fragmentationDynamic PartitioningCreate partitions as programs loadedAvoids internal fragmentation, but must deal with external fragmentationSimple PagingDivide memory into equal-size pages, load program into available pagesPages do not need to be consecutiveNo external fragmentation, small amount of internal fragmentation

Techniques Simple SegmentationDivide program into segmentsEach segment is contiguous, but different segments need not beNo internal fragmentation, some external fragmentationVirtual-Memory PagingLike simple paging, but not all pages need to be in memory at one timeAllows large virtual memory spaceMore multiprogramming, overheadVirtual Memory SegmentationLike simple segmentation, but not all segments need to be in memory at one timeEasy to share modulesMore multiprogramming, overhead

Fixed PartitioningMemory is divided into a set of partitions, each holds one programMay have same or different sizes(Figure 7.2, page 307)

Equal-sized partitionsProgram may be too large for one partitionProgrammer must handle overlaysProgram may not be big enough to need a full partitionResults in internal fragmentation

Fixed PartitioningVariable-sized partitionsCan fit partition size to program sizePlacementWhich partition do we use?Want to use smallest possible partitionWhat if there are no large jobs waiting?Can have a queue for each partition size, or one queue for all partitionsEasy to implementLimits degree of multiprocessingFixed at start time by # of partitionsTends to use memory poorly, especially for small programs (internal fragmentation)Will work if the job sizes can be predicted in advanceUsed by IBM OS/MFT, obsolete

Dynamic PartitioningCreate a new partition for each programOnly allocate space requiredTends to create holes as processes are swapped in and out (external fragmentation)Fig 7.4: pg. 310

Dynamic PartitioningTends to generate small holes in memory (external fragmentation)CompactionShifting processes so all of the available memory is in one block

Requires processor time to move items around in memory Requires relocation hardware that can handle the change in addressesCannot easily find all possible addresses in the programNeed to move program without changing user addresses

Dynamic PartitioningPlacementBest-Fit: Find the smallest available block that will hold the programTends to produce a lot of small blocksUse 30K block for 28K program, leaves 2KFirst-Fit: Find the first block that is large enough (regardless of size)May leave small blocks at the beginning, larger blocks at the end of memoryNext-Fit: Like First-Fit, but start from the last allocation instead of the startTends to break up large blocks at the end of memory that First-Fit leaves aloneComparison: Figure 7.5, page 312First-Fit generally best, fastestReplacement AlgorithmWho gets swapped out? (Chapter 8)

Buddy SystemTries to allow a variety of block sizes while avoiding excess fragmentationBlocks generally are of size 2k, for a suitable range of kInitially, all memory is one blockAll sizes are rounded up to 2sIf a block of size 2s is available, allocate itElse find a block of size 2s+1 and split it in half to create two buddiesIf two buddies are both free, combine them into a larger blockLargely Replaced by pagingSeen in parallel systems and Unix kernel memory allocation

Buddy System ExampleFigure 7.6, page 314

Representation of used and free nodes as a tree: Figure 7.7, page 315

RelocationNot a major problem with fixed-sized partitionsEasy to load process back into the same partitionOtherwise need to deal with a process loaded into a new locationMemory addresses may changeWhen loaded into a new partitionIf compaction is usedAddressesLogical AddressesAs seen by the programOften set as relative to the program startPhysical AddressesAs seen by memoryHardware does address conversion

Base/Bounds RelocationFigure 7.8, page 317

Base RegisterHolds beginning physical addressAdd to all program addressesBounds RegisterUsed to detect accesses beyond the end of the allocated memoryMay have length instead of end addressProvides protection to system Easy to move programs in memoryChange base/bounds registersLargely replaced by paging

PagingDivides memory into small (4K or less) pieces of memory (frames)Logically divide program into same-size pieces (pages)Use a page table to map the pages of the current process to the corresponding frames in memoryExample (Figure 7.9, page 318):

Paging ContinuedPage Tables for previous example (Figure 7.10, page 319)

Page size typically a power of 2 to simplify the paging hardwareExample (16-bit address, 1K pages)010101 011011010 Top 6 bits (010101)= page #Bottom 10 bits (011011010) = offset within pageCommon sizes: 512 bytes, 1K, 4K

A

B

C

D

Free

0

1

2

3

-

-

-

7

8

9

10

4

5

6

11

12

13

14

SegmentationProgram views memory as a set of segments of varying sizesEasy to handle growing data structuresEasy to share libraries, memoryPrivileges can be applied to a segmentPrograms may use multiple segmentsHave a segment tableBeginning addressSizePresent, Modified, Accessed bitsPermission/Protection bits