Operating Systems, 8e*ture 29

http:::homepage.*s.uio-a.e,u:;2ones:opsys:notes:29.shtml

Lecture 27, Dynamic Storage Allocation

Heap management for linked data structures
Part of the notes for 22C:112, Operating Systems by Douglas W. Jones T ! "#$%!&S$T' O( $OW) Department of Computer S*ien*e

Storage Allocation Services

$n the pre+ious se*tions, there ha+e been a number of referen*es to storage allo*ation an, to the sharing of storage resour*es bet-een +arious uses. for e/ample, free buffers are fre0uently share, by many ,e+i*e ,ri+ers in a 0ueue, input1output system, an, storage for user programs is fre0uently ,ynami*ally allo*ate, by the loa,er or 2ob *ontrol system. "sers of Pas*al shoul, be familiar -ith storage management ser+i*es su*h as are offere, by the new an, dispose stan,ar, library routines. C programmers shoul, re*ogni3e *orrespon,ing library routines 4no-n as malloc an, free. These straightfor-ar, storage management fun*tions are typi*ally hi,,en in ob2e*t oriente, languages, but in these languages, -hen the initiali3er for a *lass is *alle,, it must obtain memory for the ne- *lass instan*e from some-here, an, -hen the ,estru*tor is *alle,, the memory o**upie, by the instan*e being ,estroye, must go some-here. o-e+er the storage management routines of a programming en+ironment are presente, to the user, they are *ru*ial tools in programs ,ealing -ith *omple/ ,ata stru*tures su*h as lists or trees. $nsi,e most operating systems, similar routines are use, for su*h appli*ations as allo*ating primary memory to hol, segments in segmente, +irtual memory systems, allo*ating spa*e for the *o,e an, +ariables of user programs, an, allo*ating the system ,ata stru*tures themsel+es. The routines use, to manage other memory resour*es, for e/ample, ,is4 spa*e in file systems, may be 0uite similar, although laten*y *onsi,erations generally lea, to spe*ial algorithms in those *onte/ts. The follo-ing bit of Ja+a *o,e *reates a ne- ob2e*t of *lass Widget on the heap, -here the +ariable w is a referen*e to 5or ob2e*t han,le for6 that -i,get: Widget w = new Widget( params ); The follo-ing bit of C *o,e allo*ates a ne- stru*ture of type Widget on the heap, -here the +ariable w is a pointer to it. struct Widget * w = (Struct widget *)malloc( sizeof( struct Widget )); WidgetInitialize( w, params ); #oti*e that this C *o,e an, the Ja+a *o,e ,o e/a*tly the same thing, e/*ept that allo*ation an, initiali3aiton are ,istin*t from ea*h other in C, an, the C synta/ is more *umbersome. The storage region from -hi*h memory is ,ynami*ally allo*ate, in response to arbitrary user ,eman,s is usually referre, to as the heap. The term heap *learly in,i*ates the relati+e ,isor,er of the allo*ation an, ,eallo*ation re0uests, as oppose,, for e/ample, to the or,erly pattern of allo*ation an, ,eallo*ation impose, by the use of a sta*4. This use of the term heap has no relationship to the use of the same term in the *onte/t of sorting or priority 0ueues7 The heapsort sorting algorithm an, the s4e- heap 0ueue implementation ha+e absolutely nothing to ,o -ith the sub2e*t of this *hapter7 The routines for allo*ation an, ,eallo*ation from the heap are fre0uently referre, to as the heap manager *omponent of the system or language -hi*h they support. $n the follo-ing se*tions, a number of heap manager implementations -ill be ,is*usse,. all -ill be base, on the interfa*e ,es*ribe, in (igure 1.

1 sur 2<

12:<=:2<1= <>:29

Operating Systems, 8e*ture 29

http:::homepage.*s.uio-a.e,u:;2ones:opsys:notes:29.shtml

p = allocate(s) returns p, a pointer to s bytes of storage or, in the e+ent this *annot be ,one, returns NULL. ?enerally, a NULL return means that there is no free blo*4 of memory in the heap large enough to hol, s bytes of ,ata. deallocate(p,s) gi+en p, a pointer pre+iously returne, by allocate(s), returns the blo*4 of memory pointe, to by p to the heap manager for future allo*ation. the +alue of s use, in the *all to deallocate must be the same as the +alue use, in the *all to allocate an, it is an error to ,eallo*ate a parti*ular blo*4 of storage more than one time or to try ,eallo*ate using a +alue of p that -as not obtaine, by a *all to allocate. (igure 1. The user interfa*e to a storage manager. #ote that both the allocate an, deallocate ser+i*es re0uire that the si3e of the region being ,ealt -ith be passe, as a parameter. $n high le+el languages, su*h as C@@, Pas*al or Ja+a, the *ompiler *an infer the si3e of the memory region to be allo*ate, or ,eallo*ate,, so in these languages, the user ne+er e/pli*itly mentions the region si3e. Pas*al implementations learn this from the type of the pointer +ariable, -hile C@@ an, Ja+a implementations learn this from the *lass being instantiate,. Some implementations of deallocate *an infer the si3e of the region being ,eallo*ate, from the blo*4 itself, but this parameter -ill al-ays be in*lu,e, in this ,is*ussion sin*e not all implementations *an fin, this information from the ,ata stru*tures of the heap itself. $n C programs, the usual allocate *all has the form (t*)malloc(sizeof(t)) -here t is the type of the ob2e*t to be allo*ate, an, the pseu,o fun*tion sizeof(t) gi+es the si3e of an ob2e*t of type t, measure, in bytes. The *all to malloc() returns an untype, pointer 5in C, this of type ( oid*)6, so the *ast (t*) applie, to the result of the fun*iton *all *on+erts the result to a pointer to an ob2e*t of type t, as e/pe*te,. )*tually, the *asting is unne*essary in this *onte/t. $n C, a +alue of type oid* may be assigne, to any pointer +ariable, an, any pointer +alue may be assigne, to a +ariable of type oid*. Writing the *ast ma4es the type *on+ersion e/pli*it instea, of impli*it. Ay using a oid* +ariable as an interme,iary, any pointer +alue *an be assigne, to any pointer +ariable -ithout *asting, but be*ause *asting is a+ailable, C type rules *an al-ays be +iolate,, unli4e the type rules of strongly type, languages su*h as Ja+a. $t shoul, be note, that, although it is an error to ,eallo*ate the same blo*4 of storage more than on*e or to ,eallo*ate a blo*4 -hi*h -as ne+er allo*ate,, these errors are +ery har, to ,ete*t. #o *o,e is in*lu,e, in the e/amples presente, here to ,ete*t these errors, an, most real systems are not mu*h better. Typi*ally, these errors are not ,ete*te, imme,iately. instea,, the errors *orrupt the internal ,ata stru*tures of the heap, an, only later ,oes this *orruption lea, to a ,ete*table error. This, in turn, pro+i,es ample 2ustifi*ation for 4eeping the appli*ation programBs ,ata stru*tures in a separate heap from the operating system, if this -ere not ,one, it -oul, be too easy for an error in an appli*ation to *orrupt the systemBs ,ata stru*tures. $f ea*h the has its o-n heap, -e *an reinitiali3e that heap -hene+er -e start a neappli*ation, thus pre+enting the *orruption of the heap from sprea,ing from one appli*ation to another. The bul4 of this *hapter is stru*ture, as a sur+ey of heap management s*hemes. )ll of them are general purpose, in that they ,o not impose any or,ering *onstraints on allo*ations an, ,eallo*ations. (or e/ample, -e ,o not impose a last1in first1out or 8$(O *onstraint the -ay sta*4 allo*ation ,oes, nor ,o -e *onstrain a first1in first1out or ($(O *onstraint the -ay a boun,e, buffer ,oes.

Fixed Size locks

The simplest general purpose ,ynami* allo*ation me*hanism of all re0uires that all of the a+ailable storage be ,i+i,e, into e0ual si3e, blo*4s. When this is ,one, the si3e fiel, on the allo*ate an, ,eallo*ate re0uests is not +ery meaningful, sin*e only one si3e is a+ailable. $f the user re0uests more than this amount, the re0uest -ill fail. if the user re0uests less an, there are any free blo*4s, the re0uest -ill be su**essful an, an entire blo*4 -ill be allo*ate, no matter ho- little memory the user a*tually re0uests.

2 sur 2<

12:<=:2<1= <>:29

Operating Systems, 8e*ture 29

http:::homepage.*s.uio-a.e,u:;2ones:opsys:notes:29.shtml

The heap manager must maintain enough information to ,etermine -hi*h blo*4s in the heap are free at any time. Typi*ally, this information -ill be store, in the form of a lin4e, list, -here the first -or, of ea*h free blo*4 hol,s the a,,ress of the ne/t free blo*4. )s -ith *haine, resolution of for-ar, referen*es 5see (igure =.1< through (igure =.1=6, there is a problem -ith representing the en, of the free list. Throughout this se*tion, this problem -ill be ignore,, an, the symbol NULL, stan,ing for an illegal or reser+e, pointer +alue, -ill be use,. it shoul, be remembere, that there are o**asional *onte/ts -here there are no reser+e, a,,resses, re0uiring a more *omple/ solution to the problem of mar4ing the en, of a list. When -riting a heap manager in assembly language or other lo-1le+el languages, -here there is no ,ifferen*e bet-een pointers an, integers, it is natural to thin4 of memory as one big array in -hi*h it is perfe*tly appropriate to ,o arithmeti* on array in,i*es. $n higher le+el languages, -here the type system ,is*ourages or e+en pre+ents this, -e *oul, ta4e t-o approa*hes to e/plaining su*h algorithms. One approa*h is to e/plain the algorithm in terms of a large array of integers, !, -ith integer memory a,,resses. )nother is to use pointers -ith *arefully ,o*umente, an, +ery unsafe *on+ersions bet-een integer an, pointer types. $n C, for e/ample, *(int*)a is a pointer to the integer at the memory a,,ress a, -hile *(c"ar*)a refers to the *hara*ter store, at the same memory a,,ress. The +ariable a use, in these e/amples *oul, ha+e been an integer or a pointer. in either *asem, it hol,s the same memory a,,ress. $n most C implementations, the integer o**upies = su**essi+e bytes of memory starting at this a,,ress, -hile the *hara*ter o**upies only one byte at this a,,ress. "sing these *on+entions, C *o,e to allo*ate from a free list on the heap *an be -ritten as sho-n in (igure 2. t#pedef oid * pointer; $* used for unt#ped pointers *$

pointer freelist; $* pointer to t"e first free %loc& in memor# *$ pointer allocate( int size ) ' if (size ( %loc&size) ' error( )size too %ig) ); return NULL; * else if (freelist == NULL) ' error( )no space a aila%le) ); return NULL; * else ' pointer %loc&; %loc& = freelist; freelist = *(pointer *)freelist; return %loc&; * * oid deallocate( pointer %loc&, int size ); ' if (%loc& += NULL) ' *(pointer *)%loc& = freelist; freelist = %loc&; * * (igure 2. (i/e, blo*4 si3e allo*ation. )lthough fi/e, si3e blo*4 allo*ation is presente, here primarily to set the stage for more interesting allo*ation algorithms, there are many pla*es -here it is the most appropriate approa*h. When memory is ,i+i,e, into fi/e, length pages 5or se*tors on ,is46, an, a non1*ontiguous allo*ation s*heme is being use,,
C sur 2< 12:<=:2<1= <>:29

Operating Systems, 8e*ture 29

http:::homepage.*s.uio-a.e,u:;2ones:opsys:notes:29.shtml

fi/e, si3e blo*4s are *learly appropriate. (i/e, si3e blo*4s are also appropriate for those appli*ations -here all re0uests -ill be for the same si3e blo*4. This latter situation sho-s up on many systems -here the only ,ynami*ally allo*ate, storage is for input1output buffering, an, all se*tors are of the same si3e. Dore *ommonly, there -ill be t-o or three *ommon re0uest si3es. perhaps a small re0uest for ,e+i*e *ontrol blo*4s, an, a large one for input1output buffers. When this is the *ase, fi/e, blo*4 si3e allo*ation *an still be use,, but only by maintaining a separate heap for ea*h si3e. One ,isa,+antage of a fi/e, blo*4 si3e is that, if a program nee,s to *reate a ,ata stru*ture larger than the blo*4 si3e, the program must use multiple blo*4s for this stru*ture. Programmers -ho remember the early ,ays of Di*rosoftBs DOS an, )ppleBs Da*OS are li4ely to remember a time -hen the largest memory in*rment the operating system -oul, allo*ate to an appli*ation -as E=F bytes. $n those settings, many programmers -ere for*e, to -rite a-4-ar,ly stru*ture, programs to manipulate su*h things as ,atabases, images or other large ob2e*ts. )nother ,isa,+antage of a fi/e, blo*4 si3e is that, if a program nee,s blo*4s smaller than the fi/e, si3e, the stan,ar, si3e -ill be allo*ate, any-ay. )s a result, ea*h user ob2e*t -ill be store, in a *ontainer larger than ne*essary, -asting spa*e. $n ea*h blo*4 of memory allo*ate, to a user, -e refer to the unuse, spa*e as a fragment of -hat ought to be free spa*e. Ae*ause this fragment is insi,e an allo*ate, blo*4, -e refer to this problem as internal fragmentation of the a+ailable free spa*e. $n general, any storage allo*ation me*hanism -hi*h -ill, on o**asion, allo*ate blo*4s larger than the re0ueste, si3e is sai, to *ause some ,egree of internal fragmentation. )n effe*ti+e measure of the e/tent to -hi*h a storage allo*ation algorithm lea,s to internal fragmentation is the per*ent of allo*ate, spa*e -hi*h goes unuse, be*ause it is *ontaine, in internal fragments. $f the blo*4 si3es re0ueste, by users are uniformly ,istribute, bet-een one an, the allo*ate, blo*4 si3e, the fi/e, si3e blo*4 me*hanism ,es*ribe, in this se*tion -oul, result in about G<H -aste ,ue to internal fragmentation. $n fa*t, a uniform ,istribution of blo*4 si3es is 0uite un*ommon7 Dost real problems only re0uire a fe- -ell ,efine, blo*4 si3es.

!"e uddy System

One -ay of ,ealing -ith internal fragmentation is to allo- a +ariety of blo*4 si3es. Alo*4s of ea*h si3e *an be allo*ate, an, ,eallo*ate, by the use of a fi/e, si3e blo*4 allo*ate an, ,eallo*ate me*hanism su*h as that illustrate, in (igure 2, an, if a blo*4 of one si3e is not a+ailable, a larger blo*4 *an be allo*ate, an, a blo*4 of the ,esire, split off of it. When this is ,one, all blo*4s resulting from splitting a parti*ular blo*4 are *alle, bu,,ies, an, the blo*4 from -hi*h they -ere split is *alle, their parent. The resulting storage allo*ation me*hanism is sai, to use a buddy system. )ll bu,,y systems maintain an array of lists of free blo*4s, -here all blo*4s in ea*h list are the same si3e, an, the array is in,e/e, by a +alue *ompute, from the si3e. The ol,est bu,,y system, the binary buddy system has blo*4 si3es that are po-ers of t-o. Therefore, -hen a blo*4 is split, it is split e/a*tly in half, an, -hen blo*4s are *ombine,, t-o e0ual si3e blo*4s are *ombine, to ma4e a blo*4 t-i*e as big. With the binary bu,,y system, -e arrange things so that blo*4s of si3e 2n al-ays begin at memory a,,resses -here the n least signifi*ant bits are 3ero. Thus, blo*4s of si3e 1 52<6 may begin at any a,,ress, but blo*4s of si3e 2 5216 may only begin at e+en a,,resses, an, blo*4s of si3e = 5226 only begin at a,,resses -ith the least signifi*ant 2 bits e0ual to 3ero. The *onstraints on the blo*4 a,,resses in the binary bu,,y system ha+e an interesting *onse0uen*e. When a blo*4 of si3e 2n@1 is split into t-o blo*4s of si3e 2n, the a,,resses of these t-o blo*4s -ill ,iffer in e/a*tly one bit, bit n, using the *ounting s*heme that numbers bits starting -ith < at the least signifi*ant en,. Thus, gi+en a blo*4 of si3e 2n at a,,ress a, -e *an *ompute the a,,ress of its bu,,y, the other half of the blo*4 from -hi*h it -as split, by e/*lusi+e1oring a -ith 2n. This lea,s to the allo*ate routine sho-n in (igure C. t#pedef oid * pointer; $* used for unt#ped pointers *$

= sur 2<

12:<=:2<1= <>:29

Operating Systems, 8e*ture 29

http:::homepage.*s.uio-a.e,u:;2ones:opsys:notes:29.shtml

$* pointers to t"e free space lists *$ pointer freelists,sizes-; $* %loc&s in freelists,i- are of size .**i/ *$ 0define 1L234SI56(i) (7 88 (i)) $* t"e address of t"e %udd# of a %loc& from freelists,i-/ *$ 0define 1U99:2;(%,i) ((pointer)( ((int)%) < (7 88 (i)) )) pointer allocate( int size ) ' int i; $* compute i as t"e least integer suc" t"at i (= log.(size) *$ for (i = =; 1L234SI56( i ) 8 size; i>>); if (i (= sizes) ' error( )no space a aila%le) ); return NULL; * else if (freelists,i- += NULL) ' $* we alread# "a e t"e rig"t size %loc& on "and *$ pointer %loc&; %loc& = freelists,i-; freelists,i- = *(pointer *)freelists,i-; return %loc&; * else ' $* we need to split a %igger %loc& *$ pointer %loc&, %udd#; %loc& = allocate( 1L234SI56( i > 7 ) ); if (%loc& += NULL) ' $* split and put e?tra on a free list *$ %udd# = 1U99:2;( %loc&, i ); *(pointer *)%udd# = freelists,i-; freeliests,i- = %udd#; * return %loc&; * * (igure C. The binary bu,,y system. The *o,e for allocate sho-n in (igure C is re*ursi+e7 There are t-o terminating *on,itions. )s sho-n, re*ursion terminates -hen a suffi*iently large blo*4 of free spa*e is a+ailable. in this *ase, either that blo*4 is returne, ,ire*tly to the user, or it is split, perhaps repeate,ly, an, some pie*e of it is returne,. $f there is no suffi*iently large blo*4 a+ailable, the algorithm terminates -ith an error. The same error message results -hen there is not enough free spa*e as -hen the user re0uests a blo*4 larger than the largest allo-e,, be*ause the re*ursion 4eeps as4ing for larger an, larger blo*4s7 The *o,e sho-n in (igure C uses purely integer arithmeti* to ta4e the log of the re0ueste, blo*4 si3e. This is almost al-ays faster than *on+erting the blo*4 si3e to floating point, ta4ing the log, an, then roun,ing up to the nearest integer. #ote that, in C, 788i is a +ery fast -ay to *ompute 2i. )lso, note that the e/*lusi+e1or of +ariables a an, b in C is a<%. The ,eallo*ate routine for the binary bu,,y system is also re*ursi+e, as sho-n in (igure =.

G sur 2<

12:<=:2<1= <>:29

Operating Systems, 8e*ture 29

http:::homepage.*s.uio-a.e,u:;2ones:opsys:notes:29.shtml

oid deallocate( pointer %loc&, int size ) ' int i; pointer * p; pointer %udd#; $* compute i as t"e least integer suc" t"at i (= log.(size) *$ for (i = =; 1L234SI56( i ) 8 size; i>>); $* see if t"is %loc&@s %udd# is free *$ %udd# = 1U99:2;( %loc&, i ); p = Afreelists,i-; w"ile ((*p += NULL) AA (*p += %udd#)) p = (pointer *)*p; if (*p += %udd#) ' $* %udd# not free, put %loc& on its free list *$ *(pointer *)%loc& = freelists,i-; freeliest,i- = %loc&; * else ' $* %udd# found, remo e it from its free list *$ *p = *(pointer *)%udd#; $* deallocate t"e %loc& and its %udd# as one %loc& *$ if (%loc& ( %udd#) ' deallocate( %udd#, 1L234SI56( i > 7 )); * else ' deallocate( %loc&, 1L234SI56( i > 7 )); * * * (igure =. The binary bu,,y system, *ontinue,. The *o,e in (igure = -ill either fin, the blo*4Bs bu,,y ,ire*tly abo+e or belo- it in the heap, so there are t-o possible re*ursi+e *alls to ,eallo*ate, one ,ealing -ith the former *ase an, one -ith the latter. The re*ursion -ill *ontinue so long as -e 4eep fin,ing bu,,ies to *ombine -ith the su**essi+ely larger blo*4s. !+entually, -e must rea*h the point -here the blo*4Bs bu,,y is not foun, in a free list, an, at that point, the blo*4 goes in that free list -ith no further re*ursion. $n the binary bu,,y system, ea*h blo*4 has e/a*tly one bu,,y, the i,entity of -hi*h *an be ,etermine, ,ire*tly from the a,,ress an, si3e of that blo*4. )t the start, all of memory, or at least, all of the memory use, for the heap, may be a single blo*4, -hi*h is then sub,i+i,e, as re0uire,. Only -hen the user ,eallo*ates the +ery last blo*4 -oul, the bu,,y system be able to re*onstru*t this blo*4. (igure G illustrates this for a heap of 12> bytes starting at a,,ress <. BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB CBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBC = 7.D p7 = allocate(.E); BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB CFFFFFFFFFFFC$$$CBBBBBBBBBBBBBBBCBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBC = G. HE 7.D p7 p. = allocate(7.); BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB

E sur 2<

12:<=:2<1= <>:29

Operating Systems, 8e*ture 29

http:::homepage.*s.uio-a.e,u:;2ones:opsys:notes:29.shtml

CFFFFFFFFFFFC$$$CFFFFFC$CBBBBBBBCBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBC = G. ED HE 7.D p7 p. pG = allocate(.E); deallocate(p7,.E) BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB CBBBBBBBBBBBBBBBCFFFFFC$CBBBBBBBCFFFFFFFFFFFC$$$CBBBBBBBBBBBBBBBC = G. ED HE IH 7.D p. pG BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 4e# CBBBBBBCFFFFFFFFFFFFFC$$$$$$$$$$$$$$$$$C free allocated internal fragment (igure G. )n e/ample of the binary bu,,y system in use. This e/ample illustrates three things: (irst, the su**essi+e sub,i+ision of blo*4s as re0uests are ma,e, se*on,, the internal fragmentation resulting from allo*ating more than -as re0ueste,, an, thir,, the external fragmentation resulting from the brea4ing up of the free spa*e into multiple fragments. Ay the en, of the e/ample, there are t-o free blo*4s of si3e C2, but there is no -ay to *ombine these blo*4s to get a blo*4 of si3e E= shoul, one be nee,e,. The *ost of e/ternal fragmentation is not as easy to measure as that of internal fragmentation, but it *an be partially *hara*teri3e, in terms of su*h statisti*s as the a+erage number of free blo*4s an, the ,istribution of free blo*4 si3es. The t-o blo*4s of si3e 1E starting at a,,resses C2 an, => in (igure G are bu,,ies. Shoul, the blo*4 at a,,ress C2 be ,eallo*ate,, these t-o must be *ombine, into a ne- blo*4 of si3e C2 starting at a,,ress C2. This ne- blo*4 is the bu,,y of the blo*4 at a,,ress <, an, sin*e that blo*4 is also free, they must be *ombine, to ma4e a blo*4 of si3e E=. The t-o blo*4s of si3e C2 starting at a,,resses E= an, IE are also bu,,ies. What if the initial heap ,oes not begin at 3eroJ What if the si3e of the initial heap is not a po-er of 2J The ans-er use, -ith the binary bu,,y system is fairly straightfor-ar,. The rules alrea,y gi+en ,efine -hat a,,resses are legal for ea*h blo*4, so if -e start at a ran,om a,,ress, -e must follo- those rules, brea4ing the initial heap into -hate+er si3e blo*4s -or4. Consi,er a heap starting at a,,ress 1<< an, running to a,,ress 29=, as illustrate, in (igure E. BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBB CBBBCBBBBBBBCBBBBBBBBBBBBBBBCBBB BBCBBBBBBBBBBBBBBBCBC 7== 7=E 77. 7.D .JH .K. E D 7H 7.D 7H . (igure E. The initial ,i+ision of an o,, heap into free blo*4s. The heap sho-n in (igure E begins -ith one free blo*4 of si3e 2 5at a,,ress 2926, one of si3e = 5at a,,ress 1<<6, t-o of si3e 1E, an, one of si3e 12>. These blo*4s ha+e no bu,,ies in the heap, so they *an ne+er be *ombine, -ith anything else, but they may be allo*ate, to users. Some aspe*ts of the performan*e of the binary bu,,y system are easy to ,etermine. (or e/ample, if o+er a long perio, of time, re0uests for all possible blo*4 si3es are e+enly ,istribute,, the a+erage allo*ate, blo*4 -ill be about one thir, larger than re0uire, 5one 0uarter of ea*h blo*4 -ill typi*ally be -aste,, three 0uarters may be in use6. This is be*ause blo*4s of si3e s -ill only be allo*ate, to satisfy re0uests for bet-een s:2 an, s -or,s of memory. This -aste, -hi*h represents internal fragmentation, *oul, *learly be re,u*e, if there -ere a larger assortment of a+ailable blo*4 si3es. The nature of the e/ternal fragmentation is har,er to ,etermine -ithout an e/perimental measurement, an, in any *ase, the assumption of uniformly ,istribute, re0uests for ,ifferent blo*4 si3es is +ery unrealisti*. $n fa*t, programmers fre0uently prefer po-ers of t-o an, po-ers of 1< -hen ,e*i,ing on the si3es of ,ifferent ,ata stru*tures7 The (ibona**i series pro+i,es the basis for a bu,,y system +ariant that re,u*es the ,egree of internal fragmentation by pro+i,ing a -i,er +ariety of free blo*4 si3es. !a*h member of the (ibona**i series is the

9 sur 2<

12:<=:2<1= <>:29

Operating Systems, 8e*ture 29

http:::homepage.*s.uio-a.e,u:;2ones:opsys:notes:29.shtml

sum of the t-o pre+ious elements, as sho-n in (igure 9. i L = fi%(i)L = i K 2: fib5i6 L i i M 2: fib5i6 L fib5i116 @ fib5i126 (igure 9. The (ibona**i Series Of *ourse, -e are not intereste, in blo*4s too small to hol, a pointer, so if memory is byte a,,resse,, an, if pointers are C2 bits ea*h, the smallest blo*4 si3e that -e -ill use -ith this series is G bytes. $n the limit, the ratio of su**essi+e numbers in the (ibona**i series approa*hes the gol,en ratio 5appro/imately 1.E1><C6. When a blo*4 is split using the (ibona**i bu,,y system, the fragments -hi*h result are not the same si3e. thus, for e/ample, -hen a blo*4 of si3e GG is split, the results are of si3e 21 an, C=. (igure > illustrates a se0uen*e of operations using the (ibona**i bu,,y system. BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB CBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBC = JJ p7 = allocate(7J); BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB CFFFFFFFFFFFFFFC$$$$$CBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBC = .7 JJ p7 p. = allocate(7=); BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB CFFFFFFFFFFFFFFC$$$$$CFFFFFFFFFC$$CBBBBBBBBBBBBBBBBBBBBC = .7 GE JJ p7 p. deallocate(p7,7J); pG = allocate(H); BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB CFFFFFC$CBBBBBBBBBBBBCFFFFFFFFFC$$CBBBBBBBBBBBBBBBBBBBBC = D .7 GE JJ pG p. BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 4e# CBBBBBBCFFFFFFFFFFFFFC$$$$$$$$$$$$$$$$$C free allocated internal fragment (igure >. )n e/ample of the (ibona**i bu,,y system in use. With the (ibona**i bu,,y system, there is no simple formula for ,eri+ing the bu,,y of a blo*4 from information about its si3e an, lo*ation. $n (igure >, there are t-o blo*4s of si3e 1C. one of these has a bu,,y of si3e > belo- it, -hile the other has a bu,,y of si3e 21 abo+e it. Thus, the *o,e for the (ibona**i bu,,y system -ill ne*essarily be more *omple/ than that for the binary bu,,y system. The a,,itional *ost of the (ibona**i bu,,y system is offset by the re,u*tion in internal fragmentation resulting from ha+ing a more ,i+erse assortment of blo*4 si3es than the binary bu,,y system. 7 7 . 7 G . E G J J H D K 7G D .7 I GE 7= JJ 77 /// DI ///

oundary !ags
#either of the t-o bu,,y systems presente, abo+e *ompletely eliminates internal fragmentation, an, both ha+e e/ternal fragmentation problems -hi*h -ere not present -hen fi/e, si3e blo*4s -ere use,. The alternati+e is to try to allo*ate e/a*tly the amount of storage re0ueste,, thus eliminating internal fragmentation. )s -ith bu,,y systems, this -ill *learly in+ol+e splitting free blo*4s to ma4e blo*4s of the ,esire, si3e on allo*ation, an, it -ill in+ol+e merging ,eallo*ate, blo*4s -ith free neighbors to ma4e

> sur 2<

12:<=:2<1= <>:29

Operating Systems, 8e*ture 29

http:::homepage.*s.uio-a.e,u:;2ones:opsys:notes:29.shtml

larger blo*4s. "nli4e the bu,,y system, ho-e+er, there are a potentially unlimite, number of ,ifferent blo*4 si3es, so it is impra*ti*al to use ,ifferent freelists to store ea*h ,ifferent si3e of free blo*4. (urthermore, there is no restri*tion on the si3es of t-o neighboring blo*4s -hen it *omes time to merge them. )ll that matters is that they are both free, but there is no -ay to *ompute the a,,ress of the neighboring blo*4 from the a,,ress an, si3e of the blo*4 itself. )s a result of these limitations, ne- ,ata stru*tures must be intro,u*e, to allo- allo*ation of arbitrary si3e, blo*4s. These stru*tures must in*lu,e a -ay to i,entify the neighbors of any blo*4 gi+en only a pointer to that blo*4, an, they must in*lu,e enough information to ,etermine the si3e an, status of any blo*4 gi+en a pointer to it. T-o *ommon -ays of *on+eying this information are sho-n in (igure I. a6 Tags at ea*h en, BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB CBBBBBBCBBBBBBBBCBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBCBBBBBBCBBBBBBBBC C size C status C data C size C status C < C user@s pointer to %loc& b6 Tag at one en, 8MMM MMMMM( C user@s pointer to %loc& BBBBCBBBBBBBBBBCBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB CBBBBoBBBBBCBBBBoBBBBBCBBBBBBBBCBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBC C pre ious C ne?t C status C data C (igure I. Des*riptions of a blo*4 of memory. $n approa*h a illustrate, in (igure I, ea*h blo*4 is bra*4ete, -ith si3e an, status of that blo*4, thus allo-ing one en, of any blo*4 to be foun, from the other, an, allo-ing the status of a blo*4 to be inspe*te, from either en,. $n approa*h b, ea*h blo*4 is prefi/e, -ith its status an, -ith the a,,ress of ea*h of its neighbors. Aoth blo*4 ,es*ription s*hemes gi+en in (igure I are really e0ui+alent, sin*e a fiel, hol,ing the si3e of a blo*4 may be thought of as a relati+e pointer. $n effe*t, both s*hemes pla*e t-o pointers an, status information in bet-een ea*h pair of *onse*uti+e blo*4s on the heap. $n both *ases, the effe*t is to establish a ,oubly lin4e, list of blo*4s, -ith status information asso*iate, -ith ea*h blo*4. $n general, ,es*ripti+e information asso*iate, -ith a blo*4 of ,ata is *alle, a tag, an, be*ause these tag are store, in the boun,aries bet-een a,2a*ent blo*4s in the heap, heap management algorithms base, on these approa*hes are *alle, boundary tag algorithms. When boun,ary tags are use,, a separate free spa*e list is not nee,e,, sin*e a sear*h of the list of all blo*4s in the heap *an al-ays fin, all free blo*4s. o-e+er, -hen the storage utili3ation is high, only a small fra*tion of the blo*4s -ill be free, so using a separate free spa*e list *an *onsi,erably spee, up allo*ation. $n boun,ary tag systems, the stru*ture of the free spa*e list may be *ompli*ate, by the nee, to ,elete from the mi,,le of the list, for e/ample -hen a blo*4 is merge, -ith its free neighbor. $n the bu,,y system, the free neighbor -as al-ays foun, by sear*hing the freelist, so this ,eletion -as not ,iffi*ult. With boun,ary tags, though, neighbors are foun, ,ire*tly from the main list, so a ,oubly lin4e, free list may be nee,e, to allo- ,eletion from mi, list7 There are t-o basi* approa*hes to allo*ation using a boun,ary tag system, first fit an, best fit. The bu,,y system use, best fit. that is, the smallest free blo*4 large enough to satisfy a re0uest -as al-ays the one allo*ate,. Dultiple free lists sorte, by blo*4 si3e ma,e this easy. With only one free list, it is more natural to use the first blo*4 foun, that is large enough to satisfy the user, -hether or not some other blo*4 -oul, ha+e gi+en a better fit. Aest1fit allo*ation may sometimes be better than first1fit, but it is signifi*antly har,er to implement. The *hoi*e bet-een first1fit an, best1fit allo*ation ,epen,s on the ,istribution of re0uest si3es, an, this

I sur 2<

12:<=:2<1= <>:29

Operating Systems, 8e*ture 29

http:::homepage.*s.uio-a.e,u:;2ones:opsys:notes:29.shtml

,istribution ,epen,s on the appli*ation, so a rational *hoi*e bet-een the t-o approa*hes is not al-ays possible until after an appli*ation is fully ,e+elope,. $n general, best fit allo*ation is i,eal -hen an e/a*t fit is *ommon. an, it is parti*ularly ba, if e/a*t fits are un*ommon be*ause it ten,s to minimi3e the si3e of the free fragments pro,u*e,, an, this, in turn, minimi3es the li4elihoo, that these fragments -ill be of any future use. Thus, -hen re0uests are ,istribute, o+er a broa, range of ,ifferent blo*4 si3es, first fit is the metho, of *hoi*e. The typi*al boun,ary tag system ,is*usse, in the remain,er of this se*tion uses first fit allo*ation -ith a free spa*e list store, in the ,ata part of ,eallo*ate, blo*4s. The abstra*t ,ata stru*ture of our e/ample boun,ary tags is ,es*ribe, in Pas*al an, C in (igure 1<. Pas*al: t#pe %loc&ref = <tag; tag = record %ac&, ne?tL %loc&ref; case statusL (free, used) of usedL ( MM details left to t"e user MM ) freeL ( free%ac&, freene?tL %loc&ref; ) end; C: t#pedef struct tag * %loc&ref; struct tag ' %loc&ref %ac&, ne?t; enum ' free, used * status; * struct freetag ' %loc&ref %ac&, ne?t; enum ' free, used * status; $* must %e free *$ %loc&ref freene?t, free%ac&; * (igure 1<. De*larations for a boun,ary tag.

Pa*4ing blo*4s -ith the format gi+en in (igure 1< in memory -oul, result in a ,ata stru*ture su*h as is sho-n in (igure 11. C C CMMMMMMMC C %ac& CC oMMM>MM 8MM CCMMMMMMMC C ne?t CC oMMM>MMMMM C CCMMMMMMMC C C status CC used C C C CMMMMMMMC C C C C C C C user C C C C data C C C C C C C

tag

1< sur 2<

12:<=:2<1= <>:29

Operating Systems, 8e*ture 29

http:::homepage.*s.uio-a.e,u:;2ones:opsys:notes:29.shtml

%ac& free tag ne?t status free%ac& freene?t

C C C C CMMMMMMMC 8MM C CC oMMM>MMMMMMMM CCMMMMMMMC CC oMMM>MM CCMMMMMMMC C CC free C C CCMMMMMMMC C CC oMMM>MM>MMM( CCMMMMMMMC C CC oMMM>MM>MMM( CMMMMMMMC C C free C C C spaceC C C

(igure 11. Alo*4s pa*4e, in memory. )s illustrate, in (igure 11, pointers in most languages point to the first byte of the referen*e, items. $n the heap management *onte/t, ho-e+er, -e -oul, li4e the userBs pointers to an allo*ate, blo*4 to point to the userBs ,ata an, not the tag, an, it is *ommon to generali3e on this by ha+ing all system pointers also point to the that lo*ation, 2ust beyon, the tag. The si3e of blo*4s built as sho-n in (igures 29.1< an, 29.11 *an be *ompute, using arithmeti* on the pointers to a blo*4 an, its neighbor. (igure 12 illustrates this an, gi+es the *on+ersion fun*tions bet-een pointers to blo*4s an, pointers to their tags. 0define NOPSI56 sizeof( struct tag )

0define NOPQ6;(p) ((struct tag *)((int)(p) M NOPSI56)) 0define ;Q66NOPQ6;(p) ((struct freetag *)((int)(p) M NOPSI56)) 0define 1L234SI56(p) (((int)(NOPQ6;(p)M(ne?t) M (int)(p)) M NOPSI56)

(igure 12. Supporting fun*tions for boun,ary tag *o,e. The *o,e for 1L234SI56 gi+en in (igure 12 assumes that the ne?t fiel, of a tag -ill ne+er be NULL. -e -ill assure this by mar4ing the upper en, of the heap -ith an en,less ,ummy blo*4 that is allo*ate, to the system. The important thing to note is that none of our *o,e -ill e+er re0uest the si3e of blo*4s -hi*h are not mar4e, as free, an, the ,ummy blo*4 is allo*ate, so its ne/t fiel, is ne+er use,. We *an eliminate similar boun,ary problems at the en,s of the free spa*e list by ma4ing it *ir*ular, eliminating its en,s. This still re0uires a spe*ial *ase for an empty free list. in that *ase, the hea, pointer -ill be NULL. Cir*ular lin4age mil,ly *ompli*ates terminating unsu**essful sear*hes be*ause there is no null pointer at the en,. Cir*ular free lists intro,u*e the interesting possibility of rotating the free list to e+en out the ,istribution of free spa*e of ,ifferent si3es. $f the free lists is not rotate,, small blo*4s -ill ten, to a**umulate near the hea,. for some ,istributions of re0uest si3es, this may harm performan*e. )s -ith the bu,,y system, the basi* steps in allo*ating a blo*4 are to fin, a large enough blo*4, remo+e it from the free list, split it if it is too big, return any e/*ess to the free list, an, gi+e the user the remain,er. Thus, allo*ation both remo+es from an, a,,s to the free list. (igure 1C sho-s the basi* operations on the free list: %loc&ref freelist; %loc&ref remo efree( %loc&ref % ) $* remo es %loc& % from t"e free space list *$ '

11 sur 2<

12:<=:2<1= <>:29

Operating Systems, 8e*ture 29

http:::homepage.*s.uio-a.e,u:;2ones:opsys:notes:29.shtml

%loc&ref %ac&, ne?t; $* pointers to neig"%ors of % in free list *$ %ac& = ;Q66NOPQ6;(%)M(free%ac&; ne?t = ;Q66NOPQ6;(%)M(freene?t; if (%ac& == %) ' $* % is t"e onl# free %loc& *$ freelist = NULL; * else ' ;Q66NOPQ6;(%ac&)M(freene?t = ne?t; ;Q66NOPQ6;(ne?t)M(free%ac& = %ac&; $* t"e following line rotates t"e freelist *$ freelist = ne?t; * ;Q66NOPQ6;(%)M(status = used; * oid returnfree( %loc&ref % ) $* returns %loc& % to t"e free space list *$ ' %loc&ref ne?t; ;Q66NOPQ6;(%)M(status = free; if (freelist == NULL) ' $* tri ial case *$ freelist = %; ;Q66NOPQ6;(%)M(freene?t = %; ;Q66NOPQ6;(%)M(free%ac& = %; * else ' $* add %loc& to t"e free list *$ ne?t = ;Q66NOPQ6;(freelist)M(freene?t; ;Q66NOPQ6;(%)M(freene?t = ne?t; ;Q66NOPQ6;(%)M(free%ac& = freelist; ;Q66NOPQ6;(freelist)M(freene?t = %; ;Q66NOPQ6;(ne?t)M(free%ac& = %; * * (igure 1C. (ree spa*e list management for boun,ary tag allo*ation. #ote that, in the *o,e gi+en in (igure 1C, rotating the free list is +ery easy. not ,oing so -oul, re0uire a spe*ial *ase to ta4e *are of the possibility that the blo*4 being remo+e, from the free list is also the one pointe, to by the hea, pointer for the free list. When possible, blo*4s -hi*h are larger than re0ueste, shoul, be split before being returne, to the user. This *an only be ,one if the split off part of the blo*4 is large enough to hol, a ne- boun,ary tag as a prefi/ on a blo*4 hol,ing a free spa*e list entry. (or the blo*4 stru*ture use, in this e/ample, the boun,ary tag ta4es 2 pointers an, one status -or, or byte, an, a free blo*4 re0uires an a,,itional 2 pointers. On most ma*hines, therefore, it -ill not be possible to split a blo*4 unless the e/*ess is at least large enough for = pointers plus a status -or, or byte. The fa*t that -e *annot split blo*4s if the fragment being split off is smaller than some minimum implies that -e ha+e faile, to *ompletely eliminate internal fragmentation7 We ha+e merely su**ee,e, in limiting the ma/imum si3e of an internal fragment. This ma/imum is small enough to be irrele+ant to appli*ations -here the a+erage si3e of blo*4s re0ueste, by the user is +ery large, but for appli*ations su*h as list pro*essing, -here user re0uests are typi*ally for huge numbers of +ery small blo*4s, this *an be a serious problem.

12 sur 2<

12:<=:2<1= <>:29

Operating Systems, 8e*ture 29

http:::homepage.*s.uio-a.e,u:;2ones:opsys:notes:29.shtml

The 2 pointers an, a status byte or -or, ma4ing up the boun,ary tag itself *an also be *onsi,ere, as being e0ui+alent to an internal fragment of free spa*e, sin*e this spa*e is allo*ate, to the user but it must not be mo,ifie, by the user7 Thus, systems su*h as the bu,,y system -ill al-ays be better than the boun,ary tag approa*h if their a+erage internal fragment is smaller than the tag si3e itself. Sin*e the binary bu,,y system is e/pe*te, to -aste 2G per*ent of the allo*ate, memory to internal fragmentation, this suggests that the bu,,y system is the preferre, metho, for allo*ation of blo*4s smaller than about 12 -or,s. The pro*ess of splitting a blo*4 *an be ,es*ribe, as sho-n in (igure 1=. 0define !INSRLIN sizeof( struct freetag ) oid split( %loc&ref %, int s ) $* split a free %loc& from % so t"at w"at remains is at least size s *$ ' %loc&ref new, ne?t; $* assume t"at 1L234SI56(%) (= s *$ if (1L234SI56( % ) (= (s > !INSRLIN) ' new = (%loc&ref)((int)% > s > NOPSI56); ne?t = NOPQ6;(%)M(ne?t; NOPQ6;(new)M(ne?t = ne?t; NOPQ6;(new)M(%ac& = %; NOPQ6;(%)M(ne?t = new; NOPQ6;(ne?t)M(%ac& = new; returnfree(new); * * (igure 1=. Co,e to split o+ersi3e blo*4s ,o-n to si3e. Dost of this *o,e simply *reates a ne- boun,ary tag an, lin4s it into the list of tags. The most *omple/ aspe*t of this *o,e in+ol+es the test to see -hether a split is possible or -hether the e/*ess part of the blo*4 shoul, be retaine, as an internal fragment. #ote that the part of the blo*4 -hi*h has been split off is returne, imme,iately to the free spa*e list, an, that the returnfree pro*e,ure is responsible for mar4ing it as a free blo*4. This pro+i,es the foun,ation nee,e, to -rite the a*tual *o,e for boun,ary tag allo*ation, as sho-n in (igure 1G. oid * allocate( int s ) ' %loc&ref %; if (freelist == NULL) ' error( )free space e?"austed) ); return NULL; * else ' % = freelist; for (;;) ' if (1L234SI56( % ) (= s) ' remo efree( % ); split( %, s ); return ( oid *) %; * % = ;Q66NOPQ6;(%)M(freene?t; if (% == freelist) ' error( )size too %ig) ); return NULL; * * *

1C sur 2<

12:<=:2<1= <>:29

Operating Systems, 8e*ture 29

http:::homepage.*s.uio-a.e,u:;2ones:opsys:notes:29.shtml

* (igure 1G. Co,e for allo*ation using boun,ary tags. Deallo*ation is easily ,es*ribe, in terms of a merge routine, as sho-n in (igure 1E. oid merge( %loc&ref % ) $* merge % and its "ig" neig"%or if %ot" are free *$ ' %loc&ref ne?t; if (NOPQ6;(%)M(status += free) return; ne?t = NOPQ6;(%)M(ne?t; if (NOPQ6;(ne?t)M(status += free) return; $* % and ne?t are free, so we can merge t"em+ *$ remo efree(ne?t); ne?t = NOPQ6;("ig")M(ne?t; NOPQ6;("ig")M(%ac& = %; NOPQ6;(%)M(ne?t = "ig"; * oid deallocate( %loc&ref %, int s ); ' returnfree(%); merge(%); merge(NOPQ6;(%)M(%ac&); * (igure 1E. Co,e to ,eallo*ate an, merge a,2a*ent. #ote that this +ersion of ,eallo*ate ignores the si3e of the ,eallo*ate, blo*4 passe, by the user. There are +ariant boun,ary tag metho,s -here this is not the *ase. These +ariants sa+e some storage, but they rely on the user to *orre*tly remember the si3e. Sin*e the si3e allo*ate, may ,iffer from the si3e re0ueste,, it may be an unfair bur,en on users to re0uire that they 4no- the si3e a*tually allo*ate,. The +ersion of ,eallo*ate gi+en here has one hi,,en tri*4 in it: $t -oul, seem that the t-o merge operations in the *o,e *oul, be inter*hange,, but this is not the *ase7 The reason is that after the blo*4 is merge, -ith its lo- neighbor, all pointers to the blo*4 itself *ease to be +ali, be*ause the merger has eliminate, the boun,ary tag to -hi*h those pointers refer. On the other han,, -hen the blo*4 is merge, -ith its high neighbor, the tag eliminate, is at the far en, of the blo*4, so the pointer remains +ali,. Therefore, the su**essor must be merge, -ith the blo*4 before the blo*4 is merge, -ith it s pre,e*essor. $n fa*t, the *o,e gi+en here ,oes not -ipe out the boun,ary tag, so e/*hanging the or,er of the t-o *alls to the merge routine -oul, not *ause ,amage, but it -oul, be perfe*tly reasonable to *o,e both the ,eallo*ate an, merge routines so that the bo,ies of all free blo*4s -ere 3eroe, as soon as possible. -e allo- this fairly tri+ially -ith the or,er of the merges gi+en, but it -oul, be ,iffi*ult if the or,er of the merges -as re+erse,. Promptly 3eroing ,eallo*ate, memory is parti*ularly important in memory management soft-are inten,e, for use in se*ure systems, sin*e it *an guarantee that there -ill be no se*urity lea4s resulting from ,eallo*ating the memory hol,ing sensiti+e information an, then letting someone else fin, that information in a ne-ly allo*ate, but not yet initiali3e, blo*4 of memory.

Alternatives
)ll of the *o,e presente, abo+e is base, on the assumption that a,2a*ent free blo*4s shoul, be *ombine, as soon as possible -hen they are ,eallo*ate,. This results in free spa*e lists -hi*h *ontain the largest possible blo*4s, -ith the a,,e, result that most allo*ation operations -oul, be e/pe*te, to in+ol+e blo*4 splitting. $f some small blo*4 si3e is parti*ularly *ommon, it -oul, be preferable to allo- blo*4s of that

1= sur 2<

12:<=:2<1= <>:29

Operating Systems, 8e*ture 29

http:::homepage.*s.uio-a.e,u:;2ones:opsys:notes:29.shtml

si3e to a**umulate in the free list so that they *oul, be ,eallo*ate, an, reallo*ate, -ith minimum effort. This lea,s naturally to the i,ea of eliminating the merge operation entirely from the *o,e for deallocate an, ma4ing this the responsibility of allocate, -ith the rule that the allo*ate routine only attempts to merge blo*4s that are smaller than the si3e re0ueste,. When -e ,o this, -e ha+e *reate, a lazy heap manager. 8a3y heap managers are fre0uently *hara*teri3e, by the follo-ing *y*le: $nitially there is one large free blo*4. )s system operation progresses, this be*omes more an, more fragmente, by allo*ation an, ,eallo*ation operations, ,uring -hi*h a,2a*ent free blo*4s are ne+er *ombine,. !+entually, an allo*ation re0uest is ma,e -hi*h *annot be satisfie, by any single free blo*4, so a s*an of the heap is ma,e, *ombining a,2a*ent free blo*4s, after -hi*h the re0ueste, item is allo*ate, 5-ith lu*46 an, the *y*le repeats. Systems that e/hibit the *y*li* beha+ior ,es*ribe, abo+e typi*ally perform fe-er *omputations per heap management operation, on the a+erage, than those gi+en in the pre+ious se*tions. On the other han,, they are sub2e*t to o**asional e/pensi+e sear*hes of the entire heap ,uring -hi*h a,2a*ent free blo*4s are *ombine,. as a result, some *alls to allocate -ill ta4e 0uite a long time. Ae*ause of this, prompt heap managers 5the opposite of la3y ones, but not a stan,ar, term6 shoul, be use, -hen the -orst1*ase response time is of primary *on*ern, -hile la3y managers *an be use, -hen the a+erage response time is paramount. 8a3y boun,ary tag systems *an fre0uently ma4e use of a mu*h simpler free spa*e list organi3ation than -as gi+en here be*ause bat*hes of blo*4 mergers *an be ,one by a ,ire*t s*an of the main boun,ary tag list, buil,ing a *ompletely ne- free list in the pro*ess. This eliminates the nee, for a ,oubly lin4e, list. When a parti*ular blo*4 si3e is hea+ily use,, it is *ommon to maintain a spe*ial free list of blo*4s of that si3e. Programmers in languages su*h as Pas*al or C fre0uently a,, spe*ial free spa*e lists to their programs for ea*h hea+ily use, ,ynami*ally allo*ate, ,ata type. When this is ,one, the resulting storage manager *an be ,es*ribe, as employing the a best1fit allo*ation strategy for blo*4s of these *ommonly use, si3es, -hile using something else for un*ommon si3es. $f there are any re0uests for blo*4s of un*ommon si3es, there -ill usually be fe- re0uests for any parti*ular si3e, so a first fit allo*ator -ill probably be the best *hoi*e for those un*ommon si3es. There is a possibly ,isa,+antage that follo-s -hen programmers maintain their o-n free1spase lists, an, it may be serious: Doing so pre+ents the heap manager from using spa*e in those lists to meet ,eman,s for other si3es of blo*4s. )s a result, some sophisti*ate, heap managers in*lu,e spe*ial free spa*e lists for blo*4 si3es -hi*h are 4no-n to be *ommon. -hen other free spa*e resour*es are e/hauste,, the spa*e in the spe*ial lists re*laime, by the manager. (or e/ample, in a heap manager -hi*h ,efers the merger of free blo*4s, -hen a pass is ma,e o+er the heap to merge free blo*4s, any blo*4s in the spe*ial lists *an also be merge,. as a result, after ea*h merger pass, the spe*ial free lists are all empty. )nother possibility is to mi/ basi* storage management me*hanisms, using one me*hanism, for e/ample, the bu,,y system, to allo*ate small blo*4s, -hile using another, for e/ample, a boun,ary tag system, to allo*ate large blo*4s. $f this is ,one, the storage pool manage, by the bu,,y system -oul, *onsist of the bo,ies of some number of large blo*4s allo*ate, by the boun,ary tag system. )lthough the is some-hat *omple/, it *an impro+e storage utili3ation at a small run1time *ost.

Storage #ompaction and $ar%age #ollection

One approa*h to re,u*ing e/ternal fragmentation is to mo+e blo*4s in memory so that fragments *an be *ombine,. this is *alle, compacting the heap. This is mu*h easier to say than it is to ,o7 To ,o it, -e nee, a -ay to fin, an, up,ate all pointers to a blo*4 -hen -e mo+e the blo*4. $n segmente, +irtual memories, there is usually a master segment table *ontaining ,es*riptions of all of the segments in the system. $f all pointers to a segment are in,ire*t through an entry in this table, segments may easily be mo+e, to *ompa*t storage by up,ating this entry, in general, though, fin,ing all of the pointers to a blo*4 is *omputationally ,iffi*ult.

1G sur 2<

12:<=:2<1= <>:29

Operating Systems, 8e*ture 29

http:::homepage.*s.uio-a.e,u:;2ones:opsys:notes:29.shtml

Consi,er, for e/ample, the problem of *ompa*ting the storage use, by a Pas*al, C or C@@ program -hi*h has built e/tensi+e ,ata stru*tures in the heap. !a*h item allo*ate, by that program in the heap may *ontain any number of pointers to other items in the heap, an, no item may be mo+e, -ithout up,ating all of the pointers that refer to it. This is possible only -hen there is a ,es*ription of ea*h blo*4 in the heap -hi*h tells the system -hi*h -or,s in that blo*4 *ontain pointers. Some ma*hines ha+e -hat are *alle, tagge, ar*hite*tures, -here ea*h -or, has a small fiel, ,es*ribing the type of the *ontents of that -or,, but the ma2ority of ma*hines pro+i,e no help in sol+ing this problem. ) Pas*al or Ja+a *ompiler supporting heap *ompa*tion must e/pli*itly in*lu,e this information in ea*h item store, on the heap, typi*ally by in*lu,ing a spe*ial pointer to a type or *lass ,es*ription re*or, as the first -or, of ea*h ob2e*t. Doing this in Pas*al an, Ja+a is feasible be*ause these are strongly type, languages. Doing it in C or C@@ is har,er be*ause the *ompiler has less li*en*e to in*lu,e au/iliary information in a C or C@@ stru*ture. $n those languages, programmers usually assume that the pointer to a stru*ture is also a pointer to the first e/pli*itly ,e*lare, element of the stru*ture, so insertions by the *ompiler pose problems. The ability of the system to fin, all pointers to a blo*4 allo-s for more than 2ust heap *ompa*tion, it allo-s automati* re*lamation of those memory blo*4s in the heap -hi*h are no longer referen*e, by any of the userBs pointers. This is +aluable enough that it has a name, garbage collection.
The first programming language to support garbage *olle*tion -as 8$SP, a list pro*essing language ,e+elope, at D$T in the early 1IE<Bs. (or C< years, this -as the only -i,ely use, language -here programmers assume, that garbage *olle*tion -as supporte,. $n the late 1IE<Bs, the Simula BE9 programming language *ame into use. all implementations of Simula BE9 support garbage *olle*tion, but this language ne+er a*hie+e, any ,epth of mar4et penetration. The ob2e*t oriente, features of C@@ are base, on those of Simula BE9, an, most Simula BE9 programmers treat C@@ as an inferior a,aptation of the same i,eas. One reason is that fe- C@@ implementations support garbage *olle*tion. Ja+a retains most of the synta*ti* faults of C -hile attempting to re*o+er the strong points of Simula BE9, in*lu,ing garbage *olle*tion. nonetheless, Simula BE9 still seems to be a *leaner language. Despite this, the ,eep penetration of Ja+a into the mar4etpla*e is a great step for-ar, be*ause it brings garbage *olle*tion into the mainstream in a -ay that has ne+er o**urre, before in the history of *omputer s*ien*e.

$n a language implementation that supports garbage *olle*tion, so that storage -hi*h is no longer referen*e, by the user is automati*ally re*laime,, the user nee, not ma4e any *alls to a ser+i*e su*h as deallocate. in fa*t, su*h a ser+i*e nee, not e+en be pro+i,e, to the user. One approa*h to automati* storage re*lamation uses a reference count asso*iate, -ith ea*h blo*4. Dany programmers *onsi,er referen*e *ounting to be a simple form of garbage *olle*tion, but it is more properly *onsi,ere, as an inferior alternati+e to garbage *olle*tion. The referen*e *ount atta*he, to a blo*4 is initially 3ero -hen the blo*4 is allo*ate,, but it is imme,iately in*remente, -hen the pointer to that blo*4 is assigne, to any pointer +ariable. The referen*e *ount of a blo*4 is in*remente, ea*h time the pointer to that blo*4 is assigne, to a pointer +ariable, an, it is ,e*remente, ea*h time the pointer to that blo*4, store, in some pointer +ariable, is o+er-ritten -ith a pointer to something else or -hen a pointer +ariable hol,ing a pointer to that blo*4 is ,eallo*ate,. The blo*4 is ,eallo*ate, -hene+er the blo*4Bs referen*e *ount falls to 3ero. The problem -ith referen*e *ounts is that they *annot ,ete*t the fa*t that a *ir*ularly lin4e, stru*tures has been *ut loose from the remain,er of the stru*ture, an, thus, they ten, to slo-ly loose storage in en+ironments -here su*h stru*tures o**ur. &eferen*e *ounting is -i,ely use, in mo,ern file systems, but it is not generally use, in heap managers. &eal garbage *olle*tion, in *ontrast, ,oes not suffer from this problem. With garbage *olle*tion, a spe*ial routine, the garbage *olle*tor, perio,i*ally tra+erses all ,ata stru*tures a**essible to the user, mar4ing ea*h item on the heap -hi*h is en*ountere,. this is *alle, the marking phase of the garbage *olle*tor. )fter ,oing so, the garbage *olle*tor *laims all unmar4e, blo*4s as garbage an, s-eeps them into the free spa*e list. this is *alle, the sweep phase of the garbage *olle*tor. The names for these t-o phases lea, to the name for the entire algorithm, the mark sweep garbage *olle*tion algorithm.

1E sur 2<

12:<=:2<1= <>:29

Operating Systems, 8e*ture 29

http:::homepage.*s.uio-a.e,u:;2ones:opsys:notes:29.shtml

?enerally, the mar41s-eep algorithm re0uires heap ,ata stru*ture that in*lu,es a mar4 bit in ea*h item on the heap. We might store this in the status fiel, of the boun,ary tag on ea*h item. ?i+en this, the s-eep phase be*omes a simple s*an of the boun,ary tag list of the entire heap, gathering the unmar4e, blo*4s, mar4ing them as free, merging them if they are a,2a*ent, an, stringing the results onto the free list. $n the pro*ess, the mar4 bits on all blo*4s are *leare, to prepare for the ne/t mar4ing phase. The mar4ing phase is more interesting. $n its *lassi*al form, this assumes that the entire heap is rea*hable from some root item. The mar4ing phase operates by re*ursi+ely tra+ersing the items rea*hable from the root. $f, ,uring this re*ursion, an unmar4e, item is foun,, the item is imme,iately mar4e, an, then the re*ursion *ontinues. $f an alrea,y mar4e, item is foun,, it is ignore, sin*e the presen*e of a mar4 in,i*ates that it either has alrea,y been ,ealt -ith or that it is on the sta*4 of items being ,ealt -ith. The re*ursion itself, of *ourse, only follo-s the pointers store, in ea*h item, *ompletely ignoring integers, *hara*ters or other non1pointer *ontent. ?enerali3ation to multiple roots is easy, but the problem in a language su*h as Ja+a or Simula BE9 is to fin, the roots, sin*e e+ery pointer 5or ob2e*t han,le6 in the sta*4 of fun*tion a*ti+ation re*or,s is a root, as are all global pointer +ariables. The solution to this is to s*an the sta*4 an, the global +ariables for all pointers, but to ,o this, -e nee, to ha+e *omplete ,es*riptions of all a*ti+ation re*or, formats, telling us -here the pointers are in ea*h, along -ith a *omplete ,es*ription of the global +ariables.

Heap &anagement and 'irtual &emory

$n a*tual pra*ti*e, most systems use +arious *ombinations of ,ifferent storage allo*ation metho,s. This is be*ause ea*h metho, performs better un,er a ,ifferent *lass of ,eman,s. Dost Pas*al, C, an, C@@ implementations, for e/ample, rely on a sta*4 for lo*al +ariable allo*ation an, a heap, typi*ally implemente, -ith a boun,ary tag metho,, for ,ynami* or pointer +ariable allo*ation. On ma*hines -hi*h use +irtual memory, both the sta*4 an, heap areas share a single +irtual a,,ress spa*e -hi*h is *onstru*te, by a *ombination of har,-are an, soft-are from a number of pages. Thus, fi/e, si3e, blo*4s 5pages6 are allo*ate, to *reate the memory region from -hi*h the +ariable si3e blo*4s on the heap are later allo*ate,7 $nternal ,ata stru*tures in many operating systems are fre0uently allo*ate, in terms of a stan,ar, blo*4 si3e from a pool of su*h blo*4s -hi*h is 0uite in,epen,ent of the storage allo*ation me*hanism use, for allo*ation of page frames for user +irtual a,,ress spa*es. (or e/ample, +irtual a,,ress spa*es might be *ompose, of =<IE byte blo*4s, a si3e -hi*h is also appropriate for ,is4 buffers, but inappropriate for the re*or,s in ser+i*e re0uest 0ueues. the latter might be allo*ate, from a separate pool of 1E or C2 byte blo*4s. When ,ynami* ,ata stru*tures are maintaine, in +irtual memory, poor lo*ality of referen*e *an result. $t is highly li4ely that a lin4e, list, for e/ample, -ill en, up -ith ea*h list element store, in a separate page. Some heap managers ha+e been *onstru*te, -hi*h attempt to impro+e the lo*ality of heap ,ata stru*tures, for e/ample, by allo*ating su**essi+e elements of a list in the same page -hen possible. This re0uires that the free spa*e ,ata stru*tures be organi3e,, -hen possible, by page. $t also re0uires that the allocate routine be informe, of the ,esire, lo*ation of the allo*ate, storage. The Pas*al new pro*e,ure has a**ess to the a,,ress of the pointer to the ne-ly allo*ate, storage be*ause it returns its result in a parameter passe, by referen*e, -hile the C malloc fun*tion is not generally a-are of this. )s a result, an implementation of new *oul, attempt to allo*ate the ne- ,ata stru*ture in the same page as the pointer to the ne- ,ata stru*ture, -hile this -oul, be more ,iffi*ult -ith malloc. Of *ourse, e+en if new is *o,e, to allo- this, it -ill only be useful if users are *areful to *all new(element</ne?t) to e/ten, a list, instea, of using a temporary +ariable an, then assigning that temporary to the appropriate fiel, of the ,ata stru*ture. The first heap managers that trie, to 4eep lin4e, lists together in one page -ere ,e+elope, for the 8$SP programming language. )ll ,ata stru*tures in 8$SP are base, on elements that ta4e one of t-o forms, either atoms 5terminal symbols su*h as numbers or i,entifiers6, or list elements. )ll 8$SP list elements ha+e t-o pointer fiel,s, the car an, the cdr fiel,s. 5These names are ar*hai* 11 they refer to ma*ros on the $AD 9<I *omputer for N*opy a,,ress fiel,N an, N*opy ,e*rement fiel,N.6 Ay *on+ention, lists in 8$SP -ere lin4e, through the cdr fiel,s, -hile the car fiel,s -ere use, to point to in,i+i,ual list elements. )toms

19 sur 2<

12:<=:2<1= <>:29

Operating Systems, 8e*ture 29

http:::homepage.*s.uio-a.e,u:;2ones:opsys:notes:29.shtml

-ere also store, as ,ata ob2e*ts of the same si3e as a car1cdr pair, so the original 8$SP *oul, use fi/e, si3e blo*4s for e+erything, -here ea*h blo*4 hel, t-o pointers plus a tag bit. With the migration to +irtual memory systems, 8$SP garbage *olle*tors -ere -ritten that operate, by *opying all the rea*hable ,ata stru*tures from one memory region to another 5an, ba*4 again6. This is analogous to ,oing garbage *olle*tion by ma4ing a ba*4 of a file system an, then restoring from that ba*4up. This garbage *olle*tor al-ays *opie, *onse*uti+e list elements into *onse*uti+e memory lo*ations, thus greatly impro+ing the lo*atlity of referen*e of list1pro*essing *o,e. On*e it -as re*ogni3e, that *onse*uti+e list elements are usually store, *onse*uti+ely in memory, it seems -asteful to use half of the a+ailable memory to store pointers to the imme,iately follo-ing memory -or,, so a ne- list representation -as intro,u*e, 11 totally hi,,en from the user, -ho still a*te, as if ea*h list element ha, separate car an, cdr fiel,s. The ne- representation store, all the car fiel,s of the list in *onse*uti+e -or,s of a *ontiguous blo*4 of memory, -ith one tag bit per pointer in,i*ating that it -as a car pointer. The final pointer in ea*h blo*4 ha, the alternati+e tag +alue, in,i*ating that it -as a cdr pointer. This *ompa*te, list representation -as *alle, a cdr coded list.

!erminology
The rea,er shoul, be familiar -ith the follo-ing general terms after rea,ing this se*tion: d#namic storage allocation "eap allocate deallocate fi?ed size %loc&s free space list internal fragmentation e?ternal fragmentation reference counts storage compaction %udd# s#stems t"e %uddies of a %loc& %inar# %udd# s#stem ;i%onacci %udd# s#stem %est fit allocation first fit allocation %oundar# tag s#stems deferred %loc& merger gar%age collection automatic reclamation

(xercises
1. o- -oul, you re-rite the follo-ing fragment to fit on a ma*hine -here memory is allo*ate, in fi/e, si3e blo*4s of E= -or,s ea*hJ )ssume that the si3e of the array, its initiali3ation, an, the form of the input1output are all ,i*tate, by the appli*ation. t#pe N = arra# ,=//7===- of integer; ar OL <N; ' O is a pointer to an arra# of 7=== integers * I,SL integer; %egin new(O); for I L= = to 7=== do O<,I- L= =; read(I,S); O<,I- L= S; /// 2. &e*o,e the allocate routine sho-n in (igure C so that it is not re*ursi+e. C. &e*o,e the deallocate routine sho-n in (igure = to eliminate re*ursion. =. On most ma*hines, the minimum blo*4 si3e that *an be allo*ate, using the binary bu,,y system is larger than 1 byte. )ssume that you are on a mo,ern ma*hine, -ith C21bit -or,s an, >1bit bytes to ans-er the follo-ing: a6 What is the minimum blo*4 si3e. b6 What *hange shoul, you ma4e to the *o,e for allo*ate an, ,eallo*ate gi+en in (igures 29.1C an,

1> sur 2<

12:<=:2<1= <>:29

Operating Systems, 8e*ture 29

http:::homepage.*s.uio-a.e,u:;2ones:opsys:notes:29.shtml

29.1= to a**ount for this. G. &e*o,e the allocate an, deallocate routines in (igures 29.C an, 29.= so that they use la3y merger, *ombining ,eallo*ate, blo*4s only -hen nee,e, by the allo*ate routine. E. (igure E illustrates only one e/ample of the initial layout of free blo*4s using the binary bu,,y system in a memory region that ,oes not start at lo*ation 3ero or has a si3e that is not a po-er of t-o. (or an arbitrary blo*4 of si3e n, -here n is an arbitrary integer, -hat is the largest si3e of free blo*4 that is guarantee, to be a+ailableJ 5Obser+ation: 'ou 4no- that the free blo*4 -ill sometimes be of si3e n, but only -hen n is a po-er of t-o an, -hen the blo*4 begins at an a,,ress that is an integer multiple of n. That is the best *ase. ere, -e are intereste, in the -orst *ase.6 9. Write *o,e for allocate an, deallocate using the (ibona**i bu,,y system. >. )ssuming that blo*4 si3es are re0ueste, uniformly for all possible si3es bet-een one an, the ma/imum allo-e, si3e, -hat per*entage of the allo*ate, storage is e/pe*te, to be -aste, to internal fragmentation un,er the (ibona**i bu,,y systemJ 5$n ans-ering this, assume that the a+erage blo*4 si3e is large enough that you *an ignore the o,, effe*ts that o**ur for blo*4s of si3e 1 an, 2.6 I. o- many bytes -oul, it ta4e to store a boun,ary tag -ith the format sho-n in (igure 1<, -hat is the minimum free blo*4 si3e, an, -hat is the largest possible internal fragment, assuming that the status fiel, is one byte an, pointers are a6 2 bytes ea*hJ 5as on a 1E1bit *omputer6 b6 C bytes ea*hJ 5as on a C21bit *omputer -ith 1E megabytes6 *6 = bytes ea*hJ 5as on most C21bit *omputers6 1<. &e-rite the *o,e sho-n in (igures 29.12 through 29.1E so that it uses boun,ary tags -ith the follo-ing fiel,s 5those *on*erning the free list shoul, remain un*hange,6: si3e of pre+ious blo*4 si3e of this blo*4 status of this blo*4 11. &e-rite the *o,e sho-n in (igures 29.12 through 29.1E so that it uses la3y merger, that is, blo*4s are merge, only ,uring sear*hes of the free spa*e list ,one by allocate. !+ery blo*4 inspe*te, ,uring a sear*h of the free spa*e list shoul, be merge, -ith any free neighbors abo+e it after an initial *he*4 to see if it is the right si3e, but prior to gi+ing up on it if it is too small. 12. &e-rite the *o,e sho-n in (igures 29.12 through 29.1E so that no free blo*4s are merge, until no suffi*iently large blo*4 is a+ailable to satisfy a re0uest. )t that point, all a,2a*ent free blo*4s shoul, be *ombine, an, a ne- free spa*e list shoul, be built. $f possible, use a singly lin4e, free spa*e list instea, of the ,oubly lin4e, stru*ture sho-n.

)eadings
(or brief *o+erage of these issues, see Se*tion G.=.1 of The Logical Design of Operating Systems by ). C. Sha-, 5Prenti*e all, 1I9=6. (or an e+en briefer ,is*ussion, see Se*tion E.2.= of System Software by 8. 8. Ae*4 5),,ison Wesley, 1I>G6. or see Se*tions 1C.= through 1C.I of Operating Systems by . 8orin an, . D. Deitel 5),,ison Wesley, 1I>16.

1I sur 2<

12:<=:2<1= <>:29

Operating Systems, 8e*ture 29

http:::homepage.*s.uio-a.e,u:;2ones:opsys:notes:29.shtml

The *lassi* referen*e for heap management is: The Art of omputer !rogramming" #olume $" %undamental Algorithms" by D. !. Fnuth, 5Se*on, !,ition, ),,ison Wesley, 1I9G6. Se*tion 2.G *ontains an e/*ellent ,is*ussion of boun,ary tag te*hni0ues, the bu,,y system, an, fragmentation. Se*tion 2.C.G ,is*usses garbage *olle*tion an, referen*e *ounting, although only in the *onte/t of fi/e, si3e blo*4s. )nother goo, referen*e is: %undamentals of Data Structures by !. oro-it3 an, S. Sahni 5Computer S*ien*e Press, 1I9E6. This *ontains a ,is*ussion of garbage *olle*tion in Se*tion =.1< an, a ,is*ussion of storage allo*ation in Se*tion =.>. This is shallo-er than FnuthBs *o+erage, but it is more lu*i,.

2< sur 2<

12:<=:2<1= <>:29