Lecture 3 :Modularity and virtualization

Table of Contents

1. Improving a Program
2. Modularity
3. Exploring the Fact()
4. Main Techniques for Hard Modularity

How do you improve a program?

1. Increase block size (read multiple sections of data)
• Batching lessens overhead, allowing for more data take in
• Wastes work for small files that are less than batch size


2. Overlap I/O with computation

Imagine instead of waiting for I/O to finish, and then computing, and then I/O again...

...we waited for the first I/O to finish, and started computing that section at the same time the second sector was being read!



• If computation takes very little time, this is a very slight improvement as we are still waiting mostly on the I/O time
• However, even if it takes a large computation time, you still will not gain that much improvement
• Furthermore, this takes multiple buffers - one for I/O and one for computation.
The best case scenario would be if I/O took the same amount of time as computation


3. Switch to disc I/O instead of the very old and slow program I/O

• The CPU can directly talk to the controller, who copies to the RAM without having to go through the CPU
• Controller must send INTERRUPTS to CPU to let it know when it is done sending to RAM, constantly stopping the program


4. Faster hard drive, SSD (Solid State Drive), instead of disc
5. Go RAID (Redundant Array of Independent Disks) - or basically parallel disc reading

ALL these changes have a BIG problem: They require us to change our code to incorporate the ideas. It is too much of a pain to change our programs systematically; too much of a pain to run programs simultaneously. Also if one program fails, the other ones will follow. Instead we should use MODULARITY

Modularity

• Meaning you can take apart a program and put it back together in a different order
• Make useful improvements to a module one at a time
• Effect on bug finding
• Assuming B = # of bugs, M = # of modules, L = # of lines of code (millions)
• The cost of fixing a bug is porportional to the # of lines of code

Module Abstraction

"Metrics" for quality of modularity
• Independence/Neutrality : Lack of assumptions and flexibility
• Determinism/Predictability : Helps to debug application
• Simplicity : eay to use and maintain
• Cohesiveness, performance, robustness


Mechanisms for Modularity
• Mechanism 0: Write whatever you want, e.g. self modifying code. Hard to debug/change
• Mechanism 1: Function calls

brk(N) moves the break to N, able to increase/decrease the forbidden zone. If you N=0, everything is FORBIDDEN. Bad stuff happens!

Comparing Fact Function Calls

What can go wrong with function calls?

1. Hard to change conventions - complete recompilation
2. Callee can stomp on caller's storage
3. Caller is not insulated from callee disasters
4. Caller can mess with callee - both sides must trust each other
5. Callee can loop forever

Function calls are SOFT MODULARITY! We want HARD MODULARITY, which will protect modules from each other

Main Techniques for Hard Modularity

1. Client-server or peer-to-peer
• Very nice hard modularity
• SLOW
2. Virtualization
• Simplest approach : x86 emulator
• Hardware traps if you execute a dangerous instruction - HALT, INB...- also called privileged instructions
• Protected transfer of control: callee (Operating system) is protected from caller(application code)
• Still too slow, but virtualizable hardware - emulated code runs at full speed, but in a sandbox (specialized region)

---

---