Executing Environment: Garbage Collection, Virtual Machines

(実行環境、ゴミ集め、仮想計算機、動的コンパイル)

Language Theory and Compilers

The compiler compiles one source file into one relocatable program
(example: gcc -o relocatable.o relocatable.c)
Example extensions: .o (Unix/Linux) or .obj (Windows)
Main contents:
- Machine code
- Constants
- List of undefined (unresolved) symbols
- List of externally usable symbols
- List of addresses that need to be fixed on reallocation

Has to be provided together with the compiler

Dynamic memory in C:
- Obtain "raw" memory with malloc
- Give memory back with free
Dynamic memory in C++:
- Create a new object with new
  (includes memory allocation)
- Finalize an object with delete
  (includes freeing memory)
Problem:
- Locations for allocation and freeing differ
- Memory may be given back too early or never (memory leak)
Solution:
- Use special tools (dmalloc, valgrind, Purify,...)
- Garbage collection

In programming languages that do not use raw pointers, the type of each data item is fixed
This allows to detect all references to other objects
The memory of an object that is not referenced is not useable
⇒ It can be collected and reused
GC demo: garbage.rb (observe memory usage during execution with the task manager)

Advantages of GC:
- Programmers do not have to think about memory management
- Programming efficiency increases
- Memory leaks are (mostly) avoided
Problems of GC:
- GC needs time
- GC cannot run in parallel to other operations
  ⇒ program may seem to stop for a while
Currently, most programming languages (except C, C++, ObjectiveC,...) use GC

For each object, count the number of times it is referenced (reference count)
If a reference is copied (assigned), increment the count
If a reference is overwritten, decrement the count
If the count becomes 0, the memory can be reused
Advantage: Distribution of overhead (no long pauses for GC)
Disadvantages:
- Overhead during normal operation
- Objects with cyclic references cannot be garbage collected

(mark and sweep GC)

Add a flag to each object
Initially, set all flags to off (not referenced)
Recursively follow references from static memory (globals and stack),
and set the flags of all objects reached to on
Collect the memory of all objects where the flag is off
Advantage: Cyclic references correctly collected
Problem: Long pauses in execution

(usually used together with mark and sweep)

Prepare two areas for dynamic memory
Use one area for program execution
Recursively follow references and copy objects to second area
(references need to be rewritten)
Advantage: Compaction of dynamic memory
Problems: More memory needed, long pauses during execution

Some data lives long, others only a short time
Split dynamic memory into two or more generations
Garbage-collect young(er) generation(s) often
Promote objects in young(er) generation(s) after they survive GC a certain number of times
Garbage-collect old(er) generation(s) only rarely
Problem: References from older to newer generations need special care

Goal: Increase portability, simplify compiler implementation
Mechanism:
- Compiler produces code for a machine that does not exist physically
- This code is interpreted and executed by a program (emulator)
Examples: Pascal, JVM: Java Virtual Machine, Ruby 1.9~ (YARV), ...
MacIntosh: Emulating Motorola 680x0 on IBM PowerPC, emulating PowerPC on Intel i386
Problem: Slower than machine code (in general, between 3 and 10 times slower)
Similar: cygwin, wine, VMWare, VirtualBox,...
(only the OS and libraries, not the machine itself is emulated)

Goal: Improve efficiency of virtual machines and emulators
Mechanism (during program execution):
- Check execution count of functions and blocks
  ⇒ Compile frequently used functions/blocks to hardware code
- Check use of frequent parameter values (e.g. 0, 1) or types (for object-oriented and dynamic languages)
  ⇒ Recompile to optimize frequent special cases
Problems:
- Advanced technology needed
- Overhead may be greater than savings
Examples: Java HotSpot, LLVM (used by Apple), Chrome V8 (for JavaScript)

In most programs, analysis of input is more difficult than production of output
Acceptance/rejection of input can be modelled by formal language theory
Formal language theory is the basis for the front-end of compilers:
Lexical analysis and parsing
Formal language theory and knowledge about lexical analysis and parsing is useful in many other areas
Design and implementation of programming languages is still a very interesting and important area of research