Compilers. 8. Run-time Support. Laszlo Böszörmenyi Compilers Run-time - 1

Similar documents
Run-Time Environments

Example. program sort; var a : array[0..10] of integer; procedure readarray; : function partition (y, z :integer) :integer; var i, j,x, v :integer; :

Run Time Environment. Activation Records Procedure Linkage Name Translation and Variable Access

G Programming Languages - Fall 2012

Typical Runtime Layout. Tiger Runtime Environments. Example: Nested Functions. Activation Trees. code. Memory Layout

CS 345. Garbage Collection. Vitaly Shmatikov. slide 1

Principles of Programming Languages Topic: Scope and Memory Professor Louis Steinberg Fall 2004

Run-Time Environments/Garbage Collection

Concepts Introduced in Chapter 7

Intermediate Representations & Symbol Tables

G Programming Languages - Fall 2012

CS 536 Introduction to Programming Languages and Compilers Charles N. Fischer Lecture 11

Manual Allocation. CS 1622: Garbage Collection. Example 1. Memory Leaks. Example 3. Example 2 11/26/2012. Jonathan Misurda

! Those values must be stored somewhere! Therefore, variables must somehow be bound. ! How?

Runtime. The optimized program is ready to run What sorts of facilities are available at runtime

Run Time Environment. Procedure Abstraction. The Procedure as a Control Abstraction. The Procedure as a Control Abstraction

Compiler Construction

Run-time Environments - 3

Compiler Construction

Programming Languages Third Edition. Chapter 10 Control II Procedures and Environments

Lecture 13: Garbage Collection

Weeks 6&7: Procedures and Parameter Passing

Runtime Environments I. Basilio B. Fraguela

Run-time Environments - 2

G Programming Languages Spring 2010 Lecture 4. Robert Grimm, New York University

Automatic Memory Management

Acknowledgements These slides are based on Kathryn McKinley s slides on garbage collection as well as E Christopher Lewis s slides

Today's Topics. CISC 458 Winter J.R. Cordy

6.172 Performance Engineering of Software Systems Spring Lecture 9. P after. Figure 1: A diagram of the stack (Image by MIT OpenCourseWare.

CSE 504. Expression evaluation. Expression Evaluation, Runtime Environments. One possible semantics: Problem:

NOTE: Answer ANY FOUR of the following 6 sections:

Motivation for Dynamic Memory. Dynamic Memory Allocation. Stack Organization. Stack Discussion. Questions answered in this lecture:

Run-time Environments -Part 3

CMSC 330: Organization of Programming Languages

Programming Language Implementation

Heap, Variables, References, and Garbage. CS152. Chris Pollett. Oct. 13, 2008.

Run Time Environment

Design Issues. Subroutines and Control Abstraction. Subroutines and Control Abstraction. CSC 4101: Programming Languages 1. Textbook, Chapter 8

Run-Time Environments

CS 4120 Lecture 37 Memory Management 28 November 2011 Lecturer: Andrew Myers

Run Time Environments

Garbage Collection Algorithms. Ganesh Bikshandi

Procedure and Function Calls, Part II. Comp 412 COMP 412 FALL Chapter 6 in EaC2e. target code. source code Front End Optimizer Back End

CIT Week13 Lecture

Sustainable Memory Use Allocation & (Implicit) Deallocation (mostly in Java)

CMSC 330: Organization of Programming Languages

Scope, Functions, and Storage Management

Module 27 Switch-case statements and Run-time storage management

Compiler Theory. (Semantic Analysis and Run-Time Environments)

Faculty of Electrical Engineering, Mathematics, and Computer Science Delft University of Technology

CMSC 330: Organization of Programming Languages. Memory Management and Garbage Collection

Run-time Environment

Implementation Garbage Collection

Managed runtimes & garbage collection. CSE 6341 Some slides by Kathryn McKinley

Names, Bindings, Scopes

CS61C : Machine Structures

Memory Management. Memory Management... Memory Management... Interface to Dynamic allocation

Heap Management. Heap Allocation

Run-time Environments

Run-time Environments

Older geometric based addressing is called CHS for cylinder-head-sector. This triple value uniquely identifies every sector.

Managed runtimes & garbage collection

CPSC 213. Introduction to Computer Systems. Winter Session 2017, Term 2. Unit 1c Jan 24, 26, 29, 31, and Feb 2

Memory Management and Run-Time Systems

Run-Time Data Structures

Procedures and Run-Time Storage

Procedures and Run-Time Storage

Qualifying Exam in Programming Languages and Compilers

Names, Scopes, and Bindings. CSE 307 Principles of Programming Languages Stony Brook University

Memory Management. Didactic Module 14 Programming Languages - EEL670 1

Memory Management. Chapter Fourteen Modern Programming Languages, 2nd ed. 1

The Procedure Abstraction

Garbage Collection. Lecture Compilers SS Dr.-Ing. Ina Schaefer. Software Technology Group TU Kaiserslautern. Ina Schaefer Garbage Collection 1

Garbage Collection. Akim D le, Etienne Renault, Roland Levillain. May 15, CCMP2 Garbage Collection May 15, / 35

Binding and Storage. COMP 524: Programming Language Concepts Björn B. Brandenburg. The University of North Carolina at Chapel Hill

Lecture Notes on Advanced Garbage Collection

Deallocation Mechanisms. User-controlled Deallocation. Automatic Garbage Collection

Names, Scopes, and Bindings. CSE 307 Principles of Programming Languages Stony Brook University

Reference Counting. Reference counting: a way to know whether a record has other users

Project. there are a couple of 3 person teams. a new drop with new type checking is coming. regroup or see me or forever hold your peace

Reference Counting. Reference counting: a way to know whether a record has other users

Chapter 10. Implementing Subprograms ISBN

CPSC 213. Introduction to Computer Systems. Instance Variables and Dynamic Allocation. Unit 1c

CA Compiler Construction

CS 480 Fall Runtime Environments. Mike Lam, Professor. (a.k.a. procedure calls and heap management)

CS558 Programming Languages

Lecture Notes on Garbage Collection

Run-Time Environments

Chapter 5. Names, Bindings, and Scopes

CSE 504: Compilers. Expressions. R. Sekar

One-Slide Summary. Lecture Outine. Automatic Memory Management #1. Why Automatic Memory Management? Garbage Collection.

High-Level Language VMs

The basic operations defined on a symbol table include: free to remove all entries and free the storage of a symbol table

UNIT-V. Symbol Table & Run-Time Environments Symbol Table

CS 241 Honors Memory

Garbage Collection. Hwansoo Han

CS558 Programming Languages

Lecture08: Scope and Lexical Address

Topic 7: Activation Records

Lecture Notes on Garbage Collection

Transcription:

Compilers 8. Run-time Support Laszlo Böszörmenyi Compilers Run-time - 1

Run-Time Environment A compiler needs an abstract model of the runtime environment of the compiled code It must generate code for cooperation with it The run-time environment communicates with the operating system and maybe with the hardware Main tasks Storage management Handling of run-time errors Provide information for symbolic debugging Real Time (RTD) resp. Post Mortem Debugger (PMD) Hardware extensions Emulated instructions, virtual registers Laszlo Böszörmenyi Compilers Run-time - 2

Design questions for imperative languages Are procedures recursive? Are functions (procedures returning a value) supported? What should happen with local names (variables) of a procedure after return? Can non-local names be referenced? What kind of parameter passing modes and return-types are supported? Can be procedures passed as parameters or returned as a function value? Is dynamic memory management desirable? Is unused memory to be de-allocated explicitly or is a garbage-collector required? further questions for not procedure-oriented languages Laszlo Böszörmenyi Compilers Run-time - 3

Kinds of Storage Static storage Code (immutable) Static instance (or module) variables Semi-dynamic storage (stack) Allocated on procedure activation and de-allocated on return Dynamic storage (heap) Storage allocated explicitly at run time E.g. new in Java, malloc in C De-allocated explicitly E.g. free in C Or implicitly, e.g. in Java and C# By a garbage collector Code Static Data Heap free Stack Usual subdivison of run-time memory Heap and stack may be co-managed by a VMM Laszlo Böszörmenyi Compilers Run-time - 4

Activation Tree and Control Stack The activation tree describes the flow of control over the procedure call-chains 1. Each call is represented by a node 2. The root represents the activation of the main procedure 3. Node a is a parent of b iff the flow of control goes from a to b (a is calling b) 4. Node a is to the left to b iff a terminates before b Control-Stack That set of the active procedures of a call-chain Push at call (activation) Pop at return Laszlo Böszörmenyi Compilers Run-time - 5

Sketch of Quicksort class sort { int Arr[11]; // Array to be sorted: Arr[1].. Arr[9] void readarray (); { int i; } // Reads 9 integers in Arr[i]; 1 i 9 // Let assume: -9999 < Arr[i] < 9999 int partition (int m, int n); { // Partitions Arr[m..n] over a separator value V: } // Arr[m..p-1] < V and Arr[p+1..n] V; returns p void quicksort (int m, int n); { int i; if (n > m) // As long not sorted (left-right partitions distinct) i = partition(m, n); // Partition quicksort(m, i-1); // Call quicksort recursively on the left quicksort(i+1, n) // and on the right partition } } main () { readarray(); // Initialize Arr Arr[0] := -9999; Arr[10] := 9999; // Sentinel values (accelerate tests) (- and + ) quicksort(1, 9) // Initial call of quicksort on 9 elements } // class sort Laszlo Böszörmenyi Compilers Run-time - 6

Activation tree and control stack for quicksort Activation tree Control stack at q(2,3) Laszlo Böszörmenyi Compilers Run-time - 7

Activation record of a procedure At call: push activation record 1. Reserve place for return values If not returned in a register 2. Push actual parameters 3. Push actual status (registers) Temporary results of an expression 4. Push return address PC (program counter) 5. Set access (static) link Points to surrounding scope 6. Set control (dynamic) link Points to the caller s local data 7. Local and temporary variables Variable-length data: indirection: A pointer to stack or heap On return: pop in similar steps push C a ll e r C a ll e e Set by callee Returned values Actual parameters Saved status Return address static link dynamic link Local variables Temp. variables Laszlo Böszörmenyi Compilers Run-time - 8

Stack of activation records - Example Code for readarray Code for partition Code for quicksort Code for main Control stack at q(2,3) Arr[0].. Arr[10] parameter m: 1 parameter n: 9 status local variable i parameter m: 1 parameter n: 3 status local variable i parameter m: 2 parameter n: 3 status local variable i Laszlo Böszörmenyi Compilers Run-time - 9

Scoping Names are valid in a certain scope Static scoping The validity area is defined by the place in program text Nested block can access outer names (via access link) Dynamic scoping Validity is defined by actual state of variables Dynamic binding of a variable to a type e.g. class membership E.g. ((Student)person).matrNum valid, if person is instance of Student Mapping of names of variables to storage areas The compiler generates relative addresses (offsets) Run-time environment maps these to storage address During execution values are assigned to variables Name Offset Storage Value XYZ 38 100038 25 (int XYZ:= 25) Laszlo Böszörmenyi Compilers Run-time - 10

Static (lexical scoping) program sort(input, output); n = 0 var Arr : array [1.. 10] of integer; x: integer; procedure readarray; n = 1 var i: integer; begin Arr end {readarray} ; procedure exchange (i, j: integer); n = 1 begin x := Arr[i]; Arr[i] : = Arr[j]; Arr[j] := x end {exchange}; procedure quicksort(m, n: integer); n = 1 var k, v : integer; function partition(y, z: integer): integer; n = 2 var i, j : integer ; begin k, v,. exchange(i, j); end {partition} ; begin... end {quicksort} ; n: nesting begin end {sort}. level Which k and v? Arr[1].. Arr[10] x q(1, 9) access link k, v (1,9) q(1, 3) access link k, v (1,3) p(1, 3) access link i,j e(1, 3) access link Points to the valid set of q s locals Laszlo Böszörmenyi Compilers Run-time - 11 X

Fast static scoping (Display) Display d[i] points to the actual activation record at nesting level i Nesting level known at compilation Fast, but predefined length of d At call of a procedure Store d[i] in the activation record Let d[i] point to the new activation record Before returning Restore d[i] d[0] d[1] d[2] null Arr[1].. Arr[10] x q(1, 9) saved d[1] k, v (1,9) q(1, 3) saved d[1] k, v (1,3) p(1, 3) saved d[2] i,j e(1, 3) saved d[1] Laszlo Böszörmenyi Compilers Run-time - 12

Parameter passing modes Call by value 1. Value of actual parameter is computed 2. Value is assigned to formal parameter As an initialized local variable Call by reference The address of the actual parameter is passed Assignment to the formal parameter effects the act. par. Call by name (textual replacement, as a macro ) Out-dated mode Copy restore (used in remote procedure calls) Call by value and use locally Before return assign formal par. to act. par. Laszlo Böszörmenyi Compilers Run-time - 13

Parameter passing - Examples VAR i: INTEGER; a: ARRAY [1.. 2] of INTEGER; PROCEDURE P (x: INTEGER); BEGIN i := i + 1; x := x + 2; END P;... BEGIN a[1] := 10; a[2] := 20; i := 1; P(a[i]) (* P (VAR x: INTEGER);*) a[1]: 10 a[2]: 20 Call by value: a = (10, 20) Call by reference: a = (12, 20) Call by name: a = (10, 22) Copy restore: a = (12, 20) (same as ref. not always!) Laszlo Böszörmenyi Compilers Run-time - 14

Dynamic Storage Allocation Explicit allocation of variable-length blocks External (global) fragmentation Allocation methods First-fit (fast), Best-fit, Worst-fit Explicit allocation of fixed-length blocks Continuous runs for large areas Internal fragmentation Compromise: Buddy algorithm Variable length of blocks is limited to power of 2 Virtual memory management solves fragmentation Fixed-length blocks, linked together with hardware support Laszlo Böszörmenyi Compilers Run-time - 15

Garbage Collection Explicit de-allocation is error-prone Memory leaks Memory never released Bad in server code Dangling references Pointing at released memory very bad! Java, C#, Modula-3, ML, Prolog use g.c. Difficulties Careful memory usage Avoid too long pause Tree in use p q List unused r 12 15 7 37 59 9 20 Laszlo Böszörmenyi Compilers Run-time - 16

Reachability of Data Root set Data accessed directly, without a pointer E.g. in Java the static field members + stack The root set is always reachable Transitive (recursive) reachability Data that can be reached via the reachable set is reachable Set of reachable data changes at Object allocations Parameter passing and return values Reference assignments Procedure returns Laszlo Böszörmenyi Compilers Run-time - 17

Mark and Sweep Mark all reachable data function DFS(x) if x is a pointer pointing to the heap if record x is not marked Mark x for each field fi of record x DFS(x.fi) Sweep: release all unmarked data p:= first address in heap while p < last address in heap if record p is marked unmark p else let f1 be the first word of p (* is unused, because free! *) p.f1:= freelist; (* set p on the freelist:= p; front of the free list *) p:= p + (size of record p) Laszlo Böszörmenyi Compilers Run-time - 18

Let be Price for mark and sweep H: Heap size R: Size of all reachable blocks C1,C2: Number of required instructions for mark resp. sweep Cost = (C1*R + C2*H) / (H R) (usually C1 > C2) If H >> R (which is desirable): Cost ~ C2 If H >> R not true Try to get memory from the operating system Problem of the recursive algorithm Depth of recursion could be H in the worst case! Stack must be rather built explicitly on the heap itself Traversed record points back to predecessor (pointer reversal) On return, the reversed pointers have to reset (reversed again) Needs only a few additional variables for the management Laszlo Böszörmenyi Compilers Run-time - 19

Mark and Sweep - Example Laszlo Böszörmenyi Compilers Run-time - 20

Reference counting Each memory block has a reference counter If a new reference to the block is set: increment If a reference is deleted: decrement If reference counter == 0, the block is garbage Assignments must be tracked p:= q p prev.refc--; q.refc++ Makes code slow With data flow analysis Counter ops can be reduced Complex task in compiler Cycles remain undetected p q 2 3 ref. counter p q 1 4 Laszlo Böszörmenyi Compilers Run-time - 21

Copying collectors Memory is partitioned into 2 semispaces A and B Memory is allocated in A If end reached Used blocks are copied into B A is now fully free Role of A and B swaps after each run Disadvantage Half of the memory remains unused Addresses must be changed at run-time Especially bad, if memory address is used as a hash value (e.g. in legacy C code) Laszlo Böszörmenyi Compilers Run-time - 22

Short-Pause Garbage Collection Simple gc stops the world Especially bad for real-time applications E.g. during watching a movie Partial collection We collect only a little bit Generational garbage collection Many generations of memory areas Only the oldest generation is collected Very efficient, if not too much cross-generation references exist Incremental collection The reachability analysis is broken into small pieces The collector may oversee garbage But must never collect non-garbage! Typically runs in an own thread in the background Laszlo Böszörmenyi Compilers Run-time - 23