Chapter 10 Storage Management Implementation details beyond programmer’s control Storage/CPU time trade-off Binding times to storage

Storage needed for code Code –User programs –Library routines –Storage mgt routines Static/automatic/heap allocation Garbage collection, storage compaction –Loaders, interpreters, etc.

Storage needed for data objects programmer variables, constants Temps for expression evaluation, functions return, parameters Other activation record objects –Static and/or dynamic reference environment –Return point from subprogram call Input/output buffers Garbage collection bits, ptrs Tables for named heap objects (Snobol4’s Central String’s Table)

Routines that call for storage mgt Subroutine entry, return –Prolog, epilog Heap object/ class object creation, destruction Expression evaluation Parameter passing (specifically if expression is a parameter)

Programmer control issues Free facility (danger of dangling references) versus garbage collection overhead + delay in knowing when object has lost external path –Compare to virtual memory Efficient allocation of storage in blocks (C) rather than according to logical need –Reuse of freed storage an issue – compaction problems

Static storage management No run-time storage mgt Efficiency of compiler generating location for data object as offset from code section –No table or lists needed No overlays of storage Problem – we have a large tax table that we want to hide within a routine that computes taxes –Where is it defined? No recursion

Stack (automatic) storage management Efficient storage mgt – stack ptr Recursion is possible Overlays are system controlled Compiler generates location (l-value) as offset from start of activation record Scope rules (Text left this out by error)

Heap storage mgt Allocation from free list typically organized as linked list –Programmer call or creation of object Deallocation –Programmer call or garbage collection –Is freed object placed at top of list or ordered by size? Compaction for freed objects of different sizes –LISP list components are all the same size Reuse –For fixed size elements, free storage is fungible –For variable size elements, do we allocate from best fit, first (random) fit