Presentation is loading. Please wait.

Presentation is loading. Please wait.

CS 152: Programming Language Paradigms April 16 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak.

Similar presentations


Presentation on theme: "CS 152: Programming Language Paradigms April 16 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak."— Presentation transcript:

1 CS 152: Programming Language Paradigms April 16 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak www.cs.sjsu.edu/~mak

2 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 2  A grammar defines a language.  Grammar The set of all the BNF rules (or syntax diagrams)  Language The set of all the legal strings of tokens... … according to the grammar  Legal string of tokens A syntactically correct statement _ Grammars and Languages

3 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 3 Grammars and Languages, cont’d  A statement is in the language (it’s syntactically correct) if it can be derived by the grammar.  Each grammar rule “produces” a token string in the language.  The sequence of productions required to arrive at a syntactically correct token string is the derivation of the string. _

4 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 4 Grammars and Languages  Example: A very simplified expression grammar:  What strings (expressions) can we derive from this grammar? _ ::= | | ( ) ::= 0|1|2|3|4|5|6|7|8|9 ::= + | *

5 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 5 Derivations and Productions  Is (1 + 2)*3 valid in our expression language?  Yes! The expression is valid. ::= 1  ( 1 + 2 )*3 ::=  ( + 2 )*3 ::= +  ( + 2 )*3 ::= 2  ( 2 )*3 ::=  ( )*3 ::=  ( )*3 ::= ( )  ( )*3 ::= *  *3 ::= 3  3 ::=  ::=  GRAMMAR RULEPRODUCTION ::= | | ( ) ::= 0|1|2|3|4|5|6|7|8|9 ::= + | *

6 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 6 Extended BNF (EBNF) { } Surround items to be repeated zero or more times. [ ] ( )? Surround optional items.  Extended BNF (EBNF) adds meta-symbols { } and [ ]

7 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 7 Extended BNF: Repetition (One or More)  BNF: ::= |  EBNF: ::= { }

8 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 8 Extended BNF: Optional Items  BNF: ::= |.  EBNF: or: ::= [. ] ::= (. )?

9 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 9 JavaCC Compiler-Compiler  Feed JavaCC the grammar for a source language and it will automatically generate a scanner and a parser written in Java. Specify the source language tokens with regular expressions  JavaCC generates a scanner for the source language. Specify the source language syntax rules with Extended BNF  JavaCC generates a parser for the source language.

10 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 10 JavaCC Regular Expressions  Literals  Character classes  Character ranges _ Token name Token string

11 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 11 JavaCC Regular Expressions, cont’d  Alternates  Negation  Repetition _

12 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 12 JavaCC Regular Expressions, cont’d  Quantifiers _

13 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 13 JavaCC Parser Specification EBNF : JavaCC: TOKEN : { ){4}> | ){3}> | } void PhoneNumber() : {} { "-" "-" } Token specifications Production rule Java statements can go in here! ::= 0|1|2|3|4|5|6|7|8|9 ::= ::= - - Demo Terminal Literal Terminal Nonterminal

14 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 14 Static Scoping  Most modern languages use static (lexical) scoping. Scopes are determined at compile time by how the routines are nested in the source program. At runtime, variables are bound to their values as determined by the lexical scopes. The runtime display helps do the bindings.  Static scoping in Java: What value is returned by calling function g() ? int x = 0; int f() { return x ; } int g() { int x = 1; return f(); } What is the binding of this x with static scoping?

15 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 15 Dynamic Scoping  With dynamic scoping, runtime binding of variables to their values is determined by the call chain. To determine a variable’s binding, search the call chain backwards starting with the currently active routine. The variable is bound to the value of the first declared variable found with the same name. _

16 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 16 Dynamic Scoping, cont’d  Hypothetical dynamic scoping in Java: What value is returned by calling function g() ? Call chain: main  g  f How would you implement runtime dynamic scoping? int x = 0; int f() { return x ; } int g() { int x = 1; return f(); } What is the binding of this x with dynamic scoping?

17 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 17 Runtime Memory Management  In the Scheme, local data is kept on the runtime stack. RUNTIME STACK AR: main x AR: lambda a 2 2 (define proc (lambda (a b) (let ((sum (+ a b))) sum) )) (define x 2) (define y 3) (proc x y) y 3 b 3 AR: let sum 5

18 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 18 Runtime Memory Management, cont’d  All memory for the parameters and variables declared locally by a routine is allocated in the routine’s activation record.  The memory is later automatically deallocated when the activation record is popped off the stack.  What about dynamically allocated data? Memory for dynamically allocated data is kept in the “heap”. _

19 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 19 Runtime Memory Management  Divide runtime memory into four partitions. 1. Static memory executable code statically-allocated data 2. Runtime stack activation records that contain locally-scoped data 3. Heap dynamically-allocated data 4. Free memory Executable code Statically-allocated data Runtime stack Heap Top of stackHeap limit Free memory Avoid: Heap-stack collision (Out of memory error)

20 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 20 The Java Virtual Machine (JVM) Architecture

21 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 21 Java Command-Line Arguments  java -Xms -Xmx ms : initial heap size mx : maximum heap size : size in megabytes ( m | M ) or gigabytes ( g | G ) Example: java -Xms512M -Xmx2G HelloWorld

22 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 22 Runtime Heap Management  Handled by language-specific runtime routines.  C and C++ Call new/malloc to allocate memory. Call dispose/free to de-allocate.  Java Call new to allocate memory. Set the initial and maximum heap size using the -Xms and -Xmx options. Automatic garbage collection.

23 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 23 Runtime Heap Management, cont’d  Keep track of all allocated blocks of memory and all free blocks. Free blocks are “holes” caused by freeing some of the dynamically allocated objects. _

24 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 24 Runtime Heap Management, cont’d  When a new block of memory needs to be allocated dynamically, where should you put it? You can allocate it at the end of the heap, and thereby expand the size of the heap. You can find a hole within the heap that’s big enough for the block. _

25 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 25 Runtime Heap Management, cont’d  What’s the optimal allocation strategy? Find the smallest possible hole that the block will fit in. Randomly pick any hole that’s big enough.  Should you periodically compact the heap to get rid of holes and thereby reduce the size of the heap? If allocated data moves due to compaction, how do you update references (pointers) to the data?

26 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 26 Garbage Collection  Garbage collection Return a block of memory (“garbage”) to unallocated status … … when there are no longer any references to it.  Various algorithms to locate garbage. reference counts mark and sweep stop and copy generational

27 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 27 Garbage Collection, cont’d  Automatic garbage collection is great for programmers, because they don’t have to think about it. But it can slow runtime performance unpredictably. _

28 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 28 Garbage Collection: Reference Counts  Include a counter with each block of allocated memory. Increment the counter each time a pointer is set to point to the block. Decrement the counter whenever a pointer to the block is set to null (or to point elsewhere). Deallocate the block when the counter reaches 0.  Problem: Cyclic graphs The reference counts never become 0.

29 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 29 Garbage Collection: Mark and Sweep  Make a pass over the heap to mark all allocated blocks of memory that are reachable via pointers. Various marking algorithms.  Make a second pass to sweep (deallocate) blocks that are not marked. _

30 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 30 Garbage Collection: Stop and Copy  Partition the heap into two halves. Allocate memory only in one half at a time.  When an allocation fails to find a sufficiently large block of free memory … Stop Copy all allocated blocks to the other half of the heap, thereby compacting it. Update all references to the allocated blocks.  How do you update pointer values? _

31 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 31 Generational Garbage Collection  Theory: Most objects are short-lived. Long-lived object are likely to last until the end of the run of the program. _

32 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 32 Generational Garbage Collection, cont’d  Therefore, partition the heap into a new generation area and an old generation area. Allocate new objects in the new generation area.  Keep track of how long an object lives. Once an object lives past a predetermined threshold of time, migrate it to the old generation area.  The old generation area stays fairly compacted.  The new generation area needs compacting infrequently.

33 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 33 Aggressive Heap Management  Aggressive heap management means doing garbage collection frequently, even when it’s not necessary. There’s still adequate free space remaining in the heap area.  Keep the heap as small as possible. Improve reference locality. Optimize the use of physical memory when multiple programs are running. Reduce virtual memory paging.

34 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 34 Aggressive Heap Management, cont’d  Tradeoffs GC operations slow program performance. But paging to disk can be orders of magnitude slower. _

35 SJSU Dept. of Computer Science Spring 2014: April 16 CS 152: Programming Language Paradigms © R. Mak 35 Garbage Collection Research  Entire books have been written about garbage collection.  It’s still an area with opportunities for research. You can become famous by inventing a better GC algorithm! Maybe some form of adaptive GC using machine learning? _


Download ppt "CS 152: Programming Language Paradigms April 16 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak."

Similar presentations


Ads by Google