Lecture 15 run timeenvironment_2
Download as PPTX, PDF0 likes1,100 views
This document discusses run-time addressing and storage of variables in programming. It covers how variables are accessed using offsets from frames or stacks. It also discusses variable-length local data and how it can be allocated dynamically on the stack or heap. The document then covers scope, static and dynamic scoping rules, and how static links are used to access non-local variables at run-time.
![var a : array of integer; i: integer
procedure swap(x,y : integer);
var t: integer;
begin t := x; x := y; y := t; end;
begin
i := 1;
swap(i,a[i]);
write (‘i,a[i] = ’,i,a[i]);
end.
Call-by-name vs. Call-by-reference](https://image.slidesharecdn.com/lecture15runtimeenvironment2-151124080425-lva1-app6891/85/Lecture-15-run-timeenvironment_2-39-320.jpg)
Lecture 15 run timeenvironment_2
- 2. Run time Addressing • Given a variable reference in the code, how can we find the correct instance of that variable? • Things are trickier – variables can live on the stack. • Tied to issues of scope
- 3. Storage and access for locally declared data • The executing procedure uses the frame pointer to quickly access values in its stack frame as the frame pointer points to the start of the frame. • Then add the variable’s offset from the start of the frame. Calculating local data’s offset (to be stored in the symbol table) • However problem arise for variable length data
- 4. • Goal: Allow a routine to have variable-length data (i.e., dynamically-sized arrays) as local data in frame • Option 1: Allocate the variable on the heap Work with pointers to the data Auto free the data when the routine returns • Option 2: Create the variable on the stack, dynamically Effectively: Enlarge the frame as necessary Still need to work with pointers Variable-Length Local Variables
- 5. Variable Length Data return value actual parameters optional control link optional access link saved machine status local data pointer a pointer b temporaries array a array b Control link and saved status Control link and saved status ……… Pointer to a Pointer to b …. Array a Array b Activationrecord forp Activation record forq Arrays ofp Arrays ofq top Variable length data is allocated after temporaries, and there is a link to from local data to that array. top_sp
- 6. Variable-Length Local Variables Local Variables at fixed offsets from FP Dynamically sized variables use hidden pointers All references to “a” and “b” will be indirect through hidden pointers Frame
- 7. Data Access Without Nested Procedures • Does not allow nested procedure declaration – Variables are either local or global • Allocation and access to variables are simple – Global variables • Allocated static storage • Locations remain fixed and known at compile time • Access possible using statically determined address – Local variables may be accesses using top_sp pointer
- 8. Scope The scope of a variable is that portion of the programs to which the variable applies. • A variable islocal to a procedure if the declaration occurs in that procedure. • A variable is non-local to a procedure if it is not local to that procedure but the declaration occurs in an enclosing scope of that procedure. • A variable is global if it occurs in the outermost scope.
- 9. Types of Scoping • Static – scope of a variable determined from the source code. Scope A is enclosed in scope B if A's source code is nested inside B's source code. • Dynamic – current call tree determines the relevant declaration of a variable use.
- 12. Local / Non-Local Variables
- 13. Local / Non-Local Variables
- 14. Local / Non-Local Variables
- 15. Local / Non-Local Variables
- 16. The Static Link
- 17. The Static Link
- 18. The Static Link Given a variable usage... How do we find the frame containing the right variable? Assume that x is declared at lexical level M. Assume that x is used at lexical level N. (We must have N M) At runtime... Follow N-M static links to find the right frame. Use the offset of x within that frame.
- 22. Initializing the Static Link
- 23. Initializing the Static Link
- 24. • At runtime, we can’t know where the relevant activation record holding the variable exists on the stack • Use static (access) links to enable quick location – addr(x) = # static links + x's offset – Local: (0,offset) – Immediately enclosing scope: (1,offset) Runtime Addressing in Stack Allocation
- 26. To access a non-local variable
- 27. How to Maintain the Display Registers?
- 28. How to Maintain the Display Registers?
- 29. How to Maintain the Display Registers?
- 30. How to Maintain the Display Registers?
- 31. How to Maintain the Display Registers?
- 32. How to Maintain the Display Registers?
- 33. How to Maintain the Display Registers?
- 34. How to Maintain the Display Registers?
- 35. Various approaches to passing data into and out of a procedure via parameters 1. Call-by-value – data is copied at the callee into activation and any item changes do not affect values in the caller. • Ex: C parameters 2. Call-by-reference – pointer to data is placed in the callee activation and any changes made by the callee are indirect references to the actual value in the caller. • C++ - call-by-value and call-by-reference Parameter Passing
- 36. var a,b : integer procedure swap(x,y : integer); var t: integer; begin t := x; x := y; y := t; end; begin a := 1;b := 2; swap(a,b); write ('a = ',a); write ('b = ',b); end. value reference write(a) 1 2 write(b) 2 1 Call-by-value vs Call-by-reference
- 37. 3. Call-by-value-result (copy-restore) – hybrid of call-by-value and call-by-reference. Data copied at the callee. During the call, changes do not affect the actual parameter. After the call, the actual value is updated. 4. Call-by-name – the actual parameter is in-line substituted into the called procedure. This means it is not evaluated until it is used. Parameter Passing
- 38. var a: integer procedure foo(x: integer); begin a := a + 1; x := x + 1; end; begin a := 1; foo(a); write ('a = ',a); end. Value-result reference write(a) 2 3 Call-by-value-result vs. Call-by-reference
- 39. var a : array of integer; i: integer procedure swap(x,y : integer); var t: integer; begin t := x; x := y; y := t; end; begin i := 1; swap(i,a[i]); write (‘i,a[i] = ’,i,a[i]); end. Call-by-name vs. Call-by-reference
- 40. Heap • Heap is used for data that lives indefinitely or until the program explicitly deletes it • Local variables become inaccessible when their procedures end • Many language enable us to create objects or other data whose existence is not tied to their procedure activations – In C++/Java we can create objects using new keyword and may be passed to other procedures
- 41. Heap Management • Memory Manager – Allocates and deallocates space within the heap. – Serves as an interface between application programs and operating system – For some languages that need to deallocate space manually MM is responsible for implementing that. • Garbage Collector – Responsible for finding spaces within the heap that are no longer used by the program and the deallocate them – GC is an important subsystem of the memory manager
- 42. Memory Manager • Keeps track of all the free space in heap storage at all times. • Two basic functions – Allocation – • In response to some request MM produces a chunk of contiguous heap memory • If not possible then seeks to increase heap storage from virtual memory – Deallocation – • MM returns deallocated space to the pool of free space
- 43. Memory Manager • MM would be simpler if – All requests were for the same sized chunks – Storage were released in first-allocated first-deallocated style • BUT!! None is possible in most languages • MM should be prepared to – Serve requests in any order – Serve requests of any size
- 44. Properties of Memory Manager • Desired properties of MM – Space Efficiency • Should minimize the total heap spaced needed • Can be achieved by minimizing fragmentation – Program Efficiency • Should make good use of the memory to allow program to run faster • Should take advantage of ‘locality’ characteristics of program – Low Overhead • Allocation and deallocation operations should be as efficient as possible
- 45. Memory Hierarchy • Registers are managed by the generated code • All other levels are managed automatically • With each memory access the machine searches each level of the memory in succession starting from the lowest level Virtual Memory (Disk) Physical Memory 2nd-Level Cache 1st-Level Cache Registers (Processor) Typical Sizes > 2 GB 256MB-2GB 128KB-4MB 16KB-64KB 32 Words Typical Access Times 3-15 ms 100-150ns 40-60ns 5-10ns 1ns
- 46. Memory Hierarchy • Data is transferred as blocks of contiguous storage • Larger blocks are used with the slower levels of the hierarchy • Cache lines – Data blocks transferred between main memory and cache – Typically from 32 to 256 byets • Pages – Data transferred between virtual memory and main memory – Typically between 4K and 64K
- 47. Fragmentation • Variable-sized chunks of memory are allocated. • Some chunks are freed (in more-or-less random order). • The resulting free space become “fragmented”. • Need to allocate more space? • Adequate space is available ... but it is not contiguous! • Even if holes are larger than the request …. We need to split the hole …. Creating yet smaller hole Holes
- 48. Fragmentation Reduction • Control how the MM places new objects in the heap • Best-Fit Algorithm – Allocate the requested memory in the smallest available hole that is large enough – Spares larger holes for subsequent larger requests – Good strategy for real-life programs • First-Fit Algorithm – Object is placed in the first hole in which it fits – Takes less time to place objects – Overall performance is inferior to best-fit
- 49. Managing Free Space • Coalescing a recently feed chunk to the adjacent free chunk forms larger chunk – We can always use a larger chunk to do the work of small chunks of equal total size • For bins of one fixed size we don’t want to coalesce – Simple to keep track of allocation/deallocation using bit map • 1 indicates allocated • 0 indicates free
- 50. Problems with Manual Deallocation • Two common mistakes 1. Memory Leak • Failing ever to delete data that will never be referenced • Slow down the program due to increased memory usage • Critical for long running/nonstop program such as OS or server • Does not affect program correctness • Automatic garbage collection gets rid of it – Even the program may use more memory than necessary
- 51. Problems with Manual Deallocation • Two common mistakes 2. Dangling Pointer Reference • Delete some storage and try to refer to the data in the deallocated storage • Once the freed storage is reallocated any read, write or deallocation via dangling pointer can produce random effects • Dereferencing a dangling pointer creates program error hard to debug