1 / 43

Coverage

Coverage. Memory Management Structure of run-time memory Activation and Activation Record Garbage Collection. Introduction. Storage requirements: Storage is required for storing the following: The actual code segments or the program. Run time programs like libraries.

menora
Télécharger la présentation

Coverage

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Coverage • Memory Management • Structure of run-time memory • Activation and Activation Record • Garbage Collection Storage Management

  2. Introduction • Storage requirements: Storage is required for storing the following: • The actual code segments or the program. • Run time programs like libraries. • Data structures and constants defined by the programmer. • Subprogram call and return: Return points for the subprogram. • Referencing environment. • Temporary memory needed for: intermediate values of an expression, intermediate values that occur during actual parameter evaluation. • Input and output buffers. • Object allocation or memory reservation • Memory management process includes initial allocation (based on requirements), garbage collection (recovery of garbage spaces), compaction and reuse Storage Management

  3. Introduction • Initial Allocation: • First-fit method: First available space in Free-Space List is used • Best-fit method: Block with minimum number of extra spaces compared to our requirement is used • Compaction: • Partial compaction: • Only adjacent free spaces are compacted • Active blocks (blocks in use) cannot be moved • Full compaction: • Both free and active block are moved to get fully contagious free space • Object files • Relocatable object file: • Made up of binary code and data • Needs to combine other relocatable object files to convert it into executable object file Storage Management

  4. Introduction • Object files • Executable object file: • Made up of binary code and data • Can be loaded into memory and executed • No extension in UNIX or LINUX; Windows have .exe or .com or .dll (dynamic link library) • Shared object file: • A special type of relocatable object file • Can be loaded into memory and linked dynamically • Linking can be done at load or run time • Storage of executable files • ELF (Executable and Linking Format) • COFF (Common Object-File Format) • ECOFF (extension of COFF) • XCOFF (eXtended COFF) • PE (Portable Executable) Storage Management

  5. Introduction • ELF is popular in Linux • COFF is popular in Windows • Contents are divided into: text, data, bss (Block Started by Symbol), rdata (or rodata), symbol table, relocation records, etc to store executable code, data, debugging information, dynamic linking information, symbol tables, relocation information, comments, etc. • Text section is used to store program code; data section is used to store initialized data; bss section is used to uninitialized data; and rdata is used to store read-only data. • Symbol Table: • Maps symbol names and addresses • Present in every relocatable object file • Global symbols (definition and referring) and local symbols Storage Management

  6. Introduction • Relocation Records: • Associate function calls with appropriate locations. • Might include debugging information also • PE which is popular in Windows is an extension of COFF • Linker (Link Editor) • Links necessary libraries and object files together • Once linked, appropriate address changes has to be made. Symbol table is used for this purpose • Linker working with static libraries: • Static libraries are combined with the program during link time by the linker itself • Presence of any unresolved symbol (after linking process) will generate a link error • Static libraries are combined to executable program whenever they are used • Thus, multiple copies of the same library might be needed (Ex. printf and scanf in C language) Storage Management

  7. Introduction • Linker working with dynamic libraries: • Dynamic libraries (called as shared libraries or shared objects) can be loaded (at run time) at any memory location and can be linked to a program • Extension is .so in Linux and .dll in windows Linking with Static Libraries Linking with Dynamic Libraries Storage Management

  8. Introduction • Structure of run-time memory • Run-time memory depends on the compiler implementation and platform used • Platform controls the size of the stack present • Java uses heap only but C++ class objects can be allocated in static storage, stack or heap • C# uses both heap and stack depending upon what and how things are stored • Stack contains a top-of-stack pointer which points to the first available empty position of the stack Storage Management

  9. Introduction • Variables and data storage in different languages • Static storage needs to remain alive throughout the life of the program • C++: Global variables and static variables are stored in static storage area • int a; // global variables • MyClass c1; • void main () • { static int b; static MyClass c2; // static local variables. • } • Stack storage (automatic storage) • Temporary: available when function is invoked and unavailable when function is completed • C++ local variables are stored in stack Storage Management

  10. Introduction • Stack storage (automatic storage) • Stack frame: • space allocated in run-time stack • Contains spaces for the called method's argument values, local variables, a static link to the static area, and a dynamic link to the stack frame for the method that called this method. • void main () • { int a; MyClass c1; // non-static local variables. • } • Heap storage • Allocated and de-allocated using new, delete, malloc, calloc, realloc, etc • Allocation of storage onto the heap is referred to as dynamic allocation • Allocation of variables (like local variables) onto the stack dynamically is called as stack-based or automatic, as it is done automatically by the run-time system Storage Management

  11. Introduction • In C and C++ languages, memory allocation of objects can be done in static (global pool) or stack or heap • In Java, actual objects are created on heap but direct references can be on the stack or static memory. If an object contains a reference, then the reference is also on the heap • Memory allocation in Pascal: • Allocation of strings • String is represented using character bytes • First address contains the length of the string • Actual character sequence begins at second address • Unlike C language, String is not terminated with null string • var test : string; // 256 bytes are allocated by default • var test : string(100); // some implementations allow this. • Similarly, a character string can be created in C language as: • char test[256]; // 256 bytes allocated • char test[100]; // 100 bytes allocated Storage Management

  12. Introduction • Dynamic Memory Allocation: • In Pascal: • Using new and dispose • var test: ^string; • new(test); test^ := 'hello'; writeln(test ^); • dispose(test); • In C language: • Using calloc, malloc, realloc, free. • void* malloc (size_t); void free (void*); • In C++ language: Uses new and delete along with those in C. • int *ptr1 = new int; MyClass *ptr2 = new MyClass(); • void main () • { int *ptr3 = new int[50]; // dynamic memory allocation • MyClass *ptr4 = new MyClass[50]; • delete [] ptr3; delete [] ptr4; • } • delete ptr1; delete ptr2; Storage Management

  13. Introduction • new and delete allocates/de-allocates memory and also called constructor/destructor. • malloc and free only allocates/de-allocates and there is no call to constructor or destructor. • realloc can be used to change the size without loosing the original contents • char* a = (char*)malloc(sizeof(char)*12); • a = (char*)realloc(a, sizeof(char)*24); // change size. Storage Management

  14. Activation Record • Activation is created when a subprogram is called • Activation is of two parts: • Code segment: made of executable code and constants • Activation record (called as environment): made of local data, parameters, etc • Activation record is created when a subprogram is called and destroyed when the subprogram returns • The instruction in the code segment that is being executed is called as the current instruction and the pointer to it is maintained in the variable current-instruction pointer (CIP) • CIP is indicated using the program address register or instruction register (IR) present in the hardware. Generally, we call the pointer to the activation record as environment pointer. • A pointer to the current activation record is stored in the variable current-environment pointer (CEP). Storage Management

  15. Activation Record • Format of activation record is static but its size is dynamic • Dynamic link (called as control link) • Points to the top of an instance of the activation record of the caller • Return address in the activation record is called as return point Various Activation Record layouts Storage Management

  16. Activation Record • Static link (called as access link) points to the activation record of the enclosing subprogram • Occasionally, temporary storage (for evaluating expressions) and saved state (current state of the program counter and other registers) are also present in the activation record • Activation records can be allocated on heap (LISP, Scheme, …) or stack (in Pascal, Ada, C, C++, Java, C#…) • Static link is used in FORTRAN to access nonlocal variables (called as semi-static variables) of the current execution. Semi-static variables are local variables of a different function that remain in the memory only during the invocation of the specific function • In C language: No static link as there is only global scope Storage Management

  17. Activation Record void funca(int w) { int x; … funcb(x);} void funcb(int b) {...} int main() { int a; funca(a); return 0;} Storage Management

  18. Activation Record int a = 2; void funca(int w) { int x = 5; … } int main() { funca(a); return 0;} Activation Record based on different representations in C language Storage Management

  19. Activation Record • Recursion could be indicated using activation record. • Link between one activation and the next one is maintained using dynamic link int fact(int b) { if (b <= 1) return 1; else return (b * fact(b-1)); } int main() { int result; result = fact(2); return 0;} Storage Management

  20. Activation Record • Example in Pascal language var a: integer; procedure funca(var w: integer); var x: integer; procedure funcb(); begin (* funcb *) if a = 2 then funcb(); a := a + 1; end; (* funcb *) begin (* funca *) x := 5; funcb(); end; (* funca *) begin a := 2; funca(a); end. Activation Record based on different representations in Pascal Storage Management

  21. Activation Record • Dynamic Chain (call chain) • Represents the collection of dynamic links in the stack at any specific time • Local variables can be accessed by their offset (called as local_offset) from their beginning of the activation record • local_offset of the variables depend upon the language, compiler as well as the architecture • Nested subprograms • Certain non-C based static-scoped languages like FORTRAN 95, Ada and Javascript use stack-dynamic local variables and allows subprograms to be nested • To locate a non-local reference, we need to find the correct activation record instance and then determine the correct offset within that activation record instance • To locate a non-local reference, we use Static chains or Displays Storage Management

  22. Activation Record • Static Chain • Chain of static links that connects certain activation record instances • Using static link (access link), we could move from one subprogram to all its static ancestors • To find a declaration of a non-local variable, we could chase the static chain until the activation record instance (ARI) that has the variable, searching each activation record instance • Static_depth is an integer associated with a static scope whose value is the depth of nesting of that scope. • int main( ) // static_depth = 0 • { funca( ) // static_depth = 1 • { funcb( ) // static_depth = 2 • { … } // funcb ends here • } // funca ends here • func ( ) // static_depth = 1 • { … } // func ends here • } // main ends here Storage Management

  23. Activation Record • chain_offset or nesting_depth of a non-local reference is the difference between the static_depth of the reference and that of the scope where it is declared. Reference to the location is made by a pair (chain_offset, local_offset). Local_offset is the offset in the activation record of the variable being referenced Storage Management

  24. Activation Record • Static Chain Maintenance (with no parameters that are subprograms and no pass-by-name parameters): Pascal example: MAIN subprogram calls FUNCA, then FUNCA calls FUNCB • program MAIN; // static_depth = 0 • var X : integer; • procedure FUNCA(W :int);//static_depth = 1 • var B, E : integer; • procedure FUNCB; //static_depth = 2 • var C : integer; • begin { FUNCB } • C := B + X: <-----1 • end; { FUNCB } • begin { FUNCA } • FUNCB; • W := C + E; <-----2 • end; { FUNCA } • begin { MAIN } • C:= E + X; • FUNCA(4); end. { MAIN } Storage Management

  25. Activation Record • At position 1 in FUNCB: C - (0, 3) B - (1, 4) X - (2, 1) • At position 2 in FUNCA: W - (0, 3) C - (1, 3) E - (0, 5) • At position 1 in FUNCB: • C – (0,3) = 0 stands for chain_offset and 3 stands for local_offset. • Chain_offset is 0 because A is declared within FUNCB itself. • But, B & X are not declared within FUNCB. Local_offset of C is 3 because it is available at 3rd location within the ARI. • B is declared in FUNCA and thus the difference in static depth (chain_offset) is 1 and the local_offset is 4. The local_offset of variable X is 1 because the main method does not contain return address, static link, dynamic link and parameters Storage Management

  26. Activation Record • Static Chain Maintenance can be done in two ways: • Search the dynamic chain until the first ARI for the static parent is found. This is an easier process but a very slow process. • Treat procedure calls and definitions like variable references and definitions. Here, the compiler computes the nesting depth or number of enclosing scopes between the caller and the procedure that declared the called procedure. Also, store this nesting depth and send it with the call • Problems with using static chains • Non-local reference is slow if the number of scopes between reference and declaration is high • Cost of non-local references is not equal and thus time critical applications cannot be performed effectively Storage Management

  27. Activation Record • Displays: • Static links are stored in a separate stack called display • Entries in display are pointers to ARIs that have variables in referencing environment • Displays are represented as (display_offset, local_offset), where display_offset is the same as chain_offset • Display_offset is used to get the pointer into the display to the ARI with the variable • Local_offset is used to get to the variable within the ARI • Display maintenance (with no parameters that are subprograms and no pass-by-name parameters): • display_offset depends only on the static depth of the procedure whose ARI is being built • Entries in the display will be k+1 when k is the static depth of the currently executing unit (k=0 is for main program) Storage Management

  28. Activation Record • Displays: Storage Management

  29. Activation Record • Comparing Static Chains with Displays • Local access: Both perform the same way • Non-local access: Display performs faster than static chain when accessing farther away information • Displays cost the same for all non-local references • Procedure calls: Static chain performs better if they are at one or two levels of depth while display performs better otherwise • Procedure returns: Both perform similar with static chain slightly faster • If display is not stored in registers, static chain is considered to be better • Display is mainly due to registers, as registers can be accessed faster. Storage Management

  30. Activation Record • Blocks • User-defined local scope for variables • Handling of blocks can be done in two ways: • Blocks can be considered as parameterless subprograms and a separate active record and static chain can be used • Locals in blocks can be allocated at the top of the ARI. But efforts has to be made so that the block variables are removed once the block is executed. • C program example with block: Compilation error in printing of “z” • int main() • { int x = 5; // local variable • { int z = 10; printf("z = %d\n", z);} • // Compile error: z out of scope. • printf("z = %d\n", z); • printf("x = %d\n", x); • return 0; • } Storage Management

  31. Activation Record • Implementing Dynamic Scoping • Deep Access • Non-local references could be found by searching through the dynamic chain of the activation record instances • Shallow Access • Locals are stored in a central place • There is a central table with an entry for each variable name or stack per variable Shallow Access Storage Management

  32. Activation Record • Activation record is also called as stack frame and represented as: • var a, b: integer; • procedure funcb(y: integer); • begin • b := 2 * y; y := 15; • end; • procedure funca(z: integer); • var i: integer; • begin • funcb(a); • end; • { unnamed main procedure } • var c: integer; • begin • c := 10; a := 5; funca(c); • writeln(b); // returns 10 • writeln(a); // returns 5 • end. Storage Management

  33. Activation Record • var a, b: integer; • procedure funcb(var y: integer); • begin • b := 2 * y; y := 15; • end; • procedure funca(z: integer); • var i: integer; • begin • funcb(a); • end; • { unnamed main procedure } • var c: integer; • begin • c := 10; a := 5; • funca(c); • writeln(b); // returns 10 • writeln(a); // returns 15 • end. Storage Management

  34. Activation Record • Dynamic memory allocation for an array: • Example in C: • int main( ) { • int *array = new int[5]; • … • delete [] array; • return 0; • } • Example in Pascal: • program main; • var a1 : array [0 .. 4] of real; • begin • a1[0] := 10.1; • a1[1] := 11.1; • a1[2] := 12.1; • a1[3] := 13.1; a1[4] := 14.1; • end. Storage Management

  35. Activation Record • Storing double dimensional array: • Row and column size are stored on the stack • Pointer to the first value is also stored on the stack • Elements are stored on the heap • Storing of structures or records: • Example in C: • typedef struct { • int id; char name[20]; • char dept[10]; • } StudentRec; • int main( ) • { • StudentRec *Student • = new StudentRec; • … • delete Student; • } Storage Management

  36. Activation Record • Example in Pascal: • type StudentRec = record • id: integer; • name: String; • dept: String; • end; Storage Management

  37. Garbage Collection • Storage space that is no longer needed is called as garbage • C++: Programmer frees the garbage using delete function • Java: Automatic garbage collection is present and is run as a thread • Call garbage collector explicitly: System.gc() • C#: Automatic garbage collection is used for heap objects and thus no need to use destructor to free spaces • Invoke garbage collection: GC.Collect() • GC.WaitForPendingFainalizers( ) method might be used in GC.Collect( ) just to make sure that all finalization has been completed • Garbage collection is done in two methodologies: • Reference counting (eager approach) • Mark-sweep (lazy approach) • Initially heap is empty and so these continuous chain of nodes or cells is called as free_list Storage Management

  38. Garbage Collection • Coalescing: Process of returning memory to free list to make contiguous blocks of free memory • Compaction: Move the small chunks of free memory together to form a bigger free chunk • Reference Counting: • Reference count (a cell to indicate the number of pointers that are currently pointing at the cell) is stored along with each cell • Not possible to identify inaccessible circular chain Storage Management

  39. Garbage Collection • Mark Sweep • Extra bit is stored with each cell. Initially, this bit is assigned zero (means garbage) • During tracing phase, all reachable cells are marked as not garbage (set the bit to 1) • Now, all those cells that have the bit as 0 are returned to free_list • Consumes time to find the free spaces. Alternative approach is Copy Collection, which is activated only when heap is full. Copy Collection is faster than Mark Sweep but requires more space to process • Buffer Overflow (buffer overrun) • Situation in which a process attempts to store data beyond the limits or boundaries of the buffer length • One of the most common exploits used Storage Management

  40. Garbage Collection • Buffer overflow example in C language: • void f(char *str) • { char buf[16]; // strcpy copies without checking for the str length. • strcpy(buf, str); printf("%s\n", buffer); • // prints the buffer with 100 characters • // stack violation error is generated • } • int main() {char big[100]; // Create a large buffer • int i; • for(i = 0; i < 99; i++) • big[i] = 'A'; // Assign some contents to the buffer • func(big); // invoke a function with the buffer • return 0; } • C and C++ do not check for buffer overrun and thus cause buffer overflow problems. • Java throws an ArrayIndexOutOfBounds exception • C# throws an IndexOutOfRange exception Storage Management

  41. Problems with Pointers • Dangling pointers or widows: • Location in heap that is not de-allocated • Allocate a heap-dynamic variable (X) and set a pointer (A1) to point to it. • Set a second pointer (A2) to the variable (X) of the first pointer. • De-allocate the heap-dynamic variable, using the first pointer (A1). • Here, the second pointer (A2) will be a dangling pointer. Storage Management

  42. Problems with Pointers • Lost Heap-Dynamic Variables: • Heap-dynamic variable is no longer referenced by any pointer • Pointer A1 is set to point to a newly created heap-dynamic variable (X). • A1 is later set to point to another newly created heap-dynamic variable (Y). • The variable (X) initially pointed to by the pointer A1 is not pointed by any pointer and thus becomes a wasted resource. Storage Management

  43. Pointer Referencing • void * can be used to point to any type of variable and we could access an element as *(a+5) or a[5] • Explicit dereferencing (reading the pointer's designated value) and address-of operator (&) are present. • Asterisk (*) is called as the dereference operator. • int *a1 = malloc(sizeof(int)); // memory allocation • *a1 = 2; // Assigning value to it. - Explicit Dereferencing • // The following generates runtime error. • int *a1 = 1; • *a1 = 2; // Explicit Dereferencing • int test = 1; • int *another = &test; • *another = 5; // Explicit Dereferencing • printf("%d %d\n", *another, test); // Prints 5 5 Storage Management

More Related