1 Kernfach System Software WS04/05 P. Reali M. Corti.

KernfachSystem Software

WS04/05

P. Reali

M. Corti

System-Software WS 04/05

IntroductionAdmin

Lecture– Mo 13-14 IFW A 36– We 10-12 IFW A 36

Exercises– Always on Thursday

14-15 IFW A34 C. Tuduce (E)14-15 IFW C42 V. Naoumov (E)15-16 IFW A32.1 I. Chihaia (E)15-16 RZ F21 C. Tuduce (E)16-17 IFW A34 T. Frey (E)16-17 IFW A32.1 K. Skoupý (E)

IntroductionAdditional Info

Internet– Homepage http://www.cs.inf.ethz.ch/ssw/ – Inforum vis site

Textbooks & Co.– Lecture Slides– A. Tanenbaum, Modern Operating Systems– Silberschatz / Gavin, Operating Systems Concepts– Selected articles and book chapters

IntroductionExercises

Exercises are optional(feel free to shoot yourself in the foot)

– Weekly paper exercisestest the knowledge acquired in the lectureidentify troubles earlyexercise questions are similar to the exam ones

– Monthly programming assignmentfeel the gap between theory and practice

IntroductionExam

Sometimes in March 2005 Written, 3 hours Allowed help

– 2 A4 page summary– calculator

Official Q&A session 2 weeks before the exam

IntroductionLecture Goals

Operating System Concepts– bottom-up approach– no operating system course– learn most important concepts– feel the complexity of operating systems

there‘s no silver-bullet!

Basic knowledge for other lectures / term assignments– Compilerbau– Component Software– ....– OS-related assignments

IntroductionWhat is an operating system?

An operating system has two goals: Provide an abstraction of the hardware

– ABI (application binary interface)– API (application programming interface)– hide details

Manage resources– time and space multiplexing– resource protection

IntroductionOperating system target machines

Targets mainframes servers multiprocessors desktops real-time systems embedded systems

Different goals and requirements!

memory efficiency reaction time abstraction level resources security ...

IntroductionMemory vs. Speed Tradeoff

Example: retrieve a list of namesmemory time

1. Array Nn N2. List N(n+4) N/23. Bin. Tree N(n+8)

log(N)4. Hash Table 3Nn 1

N = # namesn = name length

IntroductionOperating System as resource manager

... in the beginning was the hardware!

Most relevant resources:

CPU Memory Storage Network

IntroductionLecture Topics

MemoryCPU Network

Scheduling

Virtual Memory

Demand Paging

Thread

Process

Coroutine

Memory Management

Garbage CollectionConcurrencySupport

File System

Object-OrientedRuntime Support

DistributedFile-System

DistributedObject-System

Virtual Machine

Runtime support

IntroductionA word of warning....

Most of the topics may seem simple.....

.... and in fact they are!

Problems are mostly due to: complexity when integrating system low-level („bit fiddling“) details bootstrapping (X needs Y, Y needs X)

Storage

Modules

Processor

Memory

Interrupts

ActiveTraps

TimersSMP

IntroductionBootstrapping (Aos)

IntroductionLecture Topics

Overview

Runtime Support

Virtual Addressing

Memory Management

Distributed Obj. System

Concurrency

Disc / Filesystem

Case Study: JVM

Run-time SupportOverview

Support for programming abstractions– Procedures

calling conventions parameters

– Object-Oriented Model objects methods (dynamic dispatching)

– Exceptions Handling– ... more ...

Call a.P Call b.Q Call b.q Call b.q Return b.q Return b.q Call c.R Return c.R Return b.QReturn a.P

Run-time SupportApplication Binary Interface (ABI)

Object a, b, c, … with methods P, Q, R, … and internal procedures p, q, r, …

Call SequenceStack

Pointer (SP)

ProcedureActivation

Frame (PAF)a.P

locals

params

Run-time SupportProcedure Activation Frame

DynamicLink

FramePointer (FP)

Save RegistersPush ParametersSave PCBranchSave FPFP := SPAllocate Locals

Remove Locals Restore FPRestore PCRemove ParametersRestore Registers

FP‘PC

StackPointer (SP)

CallerFrame

Return

Run-time SupportProcedure Activation Frame, Optimizations

Many optimizations are possible– use registers instead of stack– register windows– procedure inlining– use SP instead of FP addressing

Run-time SupportProcedure Activation Frame (Oberon / x86)

push paramscall P push fp

mov fp, spsub sp, size(locals)

mov sp, fppop fpret size(params)

Caller Callee

push pcpc := P

pop pcadd sp,size(params)

Run-time SupportCalling Convention

Convention between caller and callee– how are parameters passed

data layout left-to-right, right-to-left registers register window

– stack layout dynamic link static link

– register saving reserved registers

Run-time SupportCalling Convention (Oberon)

Parameter passing:– on stack (exception: Oberon/PPC uses registers)– left-to-right– self (methods only) as last parameter– structs and arrays passed as reference, value-parameters

copied by the callee Stack

– dynamic link– static link as last parameter (for local procedures)

Registers– saved by caller

Run-time SupportCalling Convention (C)

Parameter passing:– on stack – right-to-left– arrays passed as reference (arrays are pointers!)

Stack– dynamic link

Registers– some saved by caller

Run-time SupportCalling Convention (Java)

Parameter passing– left-to-right– self as first parameter– parameters pushed as operands– parameters accessed as locals– access through symbolic, type-safe operations

Run-time SupportObject Oriented Support, Definitions

Obj x = new ObjA();

• static type of x is Obj• dynamic type of x is ObjA

x compiled as being compatible with Obj, but executes as ObjA.

static and dynamic type can be different the system must keep track of the

dynamic type with an hidden„type descriptor“

Class Hierarchy

Polymorphism

Run-Time SupportPolymorphism

VARt: Triangle;s: Square;o: Figure;

BEGINt.Draw();s.Draw();o.Draw();

WHILE p # NIL DOp.Draw(); p := p.next

Type is discovered at runtime!

Type is statically known!

Run-time SupportObject Oriented Support, Definitions

Obj x = new ObjA();

if (x IS ObjA) { ... }// type test

ObjA y = (ObjA)x// type cast

x = y;// type coercion// (automatic convertion)

Class Hierarchy

Run-time SupportObject Oriented Support (High-level Java)

.... a IS T ....

if (a != null) {Class c = a.getClass();while ((c != null) && (c != T)) {

c = c.getSuperclass();}return c == T;

} else {return false;

Type Test Implementation

Run-Time SupportType Descriptors

struct TypeDescriptor {int level;type[] extensions;method[] methods;

class Object {TypeDescriptor type;

many type-descriptor layouts are possible

layout depends on the optimizations choosen

Run-Time SupportType Tests and Casts

ObjAObjB

0: Obj01: NIL2: NIL3: NIL

TD(Obj0)

TD(Obj)

0: Obj01: Obj2: NIL3: NIL

0: Obj01: Obj2: ObjA3: NIL

TD(ObjA)

(obj IS T)

obj.type.extension[ T.level ] = T

mov EAX, objmov EAX, -4[EAX]cmp T, -4 * T.level - 8[EAX]bne ....

“extension level”

Run-time SupportObject Oriented Support (High-level Java)

.... a.M(.....) ....

Class[] parTypes = new Class[params.Length()];for (int i=0; i< params.Length(); i++) {

parTypes[i] = params[i].getClass();}Class c = a.getClass();Method m = c.getDeclaredMethod(“M”, parTypes);res = m.invoke(self, parValues);

Method Call Implementation

Use method implementation for the actual

class(dynamic type)

Disadvantages:• memory usage• bad integration (explicit self)• non constantAdvantages:• instance bound• can be changed at run-time

Run-Time SupportHandlers / Function Pointers

TYPESomeType = POINTER TO SomeTypeDesc;Handler = PROCEDURE (self: SomeType; param: Par);SomeTypeDesc = RECORD

handler: Handler;next: SomeType;

handler

next handler

PROC Q

PROC R

Run-Time SupportMethod tables (vtables)

TYPEA = OBJECT

PROCEDURE M0;PROCEDURE M1;

END A;

B = OBJECT (A)PROCEDURE M0;PROCEDURE M2;

END B;

B.M0 overrides A.M0

B.M2 is new

0: A.M0

1: A.M1

A.MethodTable

0: A.M0

1: A.M1

B.MethodTable

2: B.M2

Idea:have a per-type table of function pointers.

• New methods add a new entry in the method table• Overrides replace an entry in the method table• Each method has an unique entry number

Run-Time SupportMethod tables

TYPEA = OBJECT

PROCEDURE M0;PROCEDURE M1;

END A;

B = OBJECT (A)PROCEDURE M0;PROCEDURE M2;

END B;

0: A.M0

1: A.M1

A.MethodTable

0: A.M0

1: A.M1

B.MethodTable0: B.M0

2: B.M2

Virtual Dispatch

call o.Type.Methods[0]

mov eax, VALUE(o)mov eax, type[eax]mov eax, off + 4*mno[eax]call eax

Fields

Run-Time SupportOberon Type Descriptors

obj size

obj fields

ext table

mth table

type name

type desc

td size

type desc

• method table• superclass table• pointers in object for GC

type descriptor is also an object!

type desc

ptr offsetsfor garbage collection

for object allocation

for type checks

for method invocation

Run-Time SupportInterfaces, itables

interface A {void m();

interface B {void p();

Object x;A y = (A)x;

y.m();

does x implement A?

x has an method table (itable) for each

implemented interface

multiple itables:how is the right itable

discovered?

Run-Time SupportInterface support

How to retrieve the right method table (if any)? Global table indexed by [class, interface] Local (per type) table / list indexed by

[interface]

Many optimizations are availableuse the usual trick:

enumerate interfaces

Run-Time SupportInterface support (I)

methodtable(vtable)

interfaces

methodtable(itable)

Type Descriptor

Intf0 y = (Intf0)x;y.M();

interface i = x.type.interfaces;while ((i != null) && (i != Intf0) {

i = i.next;}if (i != null) i.method[mth_nr]();

Call is expensive because requires traversing a list: O(N) complexity

Run-Time SupportInterface support (II)

vtable

interfaces

itable2

itable7

1 2 3 4 5 6 7 sparse array!

Intf0 y = (Intf0)x;y.M();

interface i = x.type.interfaces[Intf0];

if (i != null) i.method[mth_nr]();

Lookup is fast (O(1)), but wastes

memory

Type Descriptor

Run-Time SupportInterface Implementation (III)

vtablet

interfaces

itablet,2

itablet,7

1 2 3 4 5 6 7vtablet

interfaces

itableu,2

itableu,0

0 1 2 3 4 5 6 7

overlapinterface table

indexType Descriptor t

Type Descriptor u

vtable

interfaces

itable

vtable

interfaces

itable

overlappedinterface table indexType Descriptor

Type Descriptor

vtable

interfaces

itable

overlappedinterface

tables

Type DescriptorIntf0 y = (Intf0)x;y.M();

itable i = x.type.interfaces[Intf0];

if ((i != null) && (i in x.type))i.method[mth_nr]();

Run-Time Support Exceptions

void catchOne() {

tryItOut();

} catch (TestExc e) {

handleExc(e);

void catchOne()0 aload_01 invokevirtual tryItOut();4 return5 astore_16 aload_07 aload_18 invokevirtual handleExc11 return

ExceptionTableFrom To Target Type0 4 5 TestExc

Run-Time Support Exception Handling / Zero Overhead

void ExceptionHandler(state){

pc = state.pc, exc = state.exception;

while (!Match(table[i], pc, exc)){

i++;if (i == TableLength) {

PopActivationFrame(state); pc = state.pc; i = 0;

}}state.pc = table[i].pchandler;ResumeExecution(state)

try {.....

} catch (Exp1 e) {.....

} catch (Exp2 e) {.....

pcstart

pchandler1

pchandler2

start end exception handler

pcstart pcend Exp1 pchandler1

pcstart pcend Exp2 pchandler2

Global Exception Table

Run-Time Support Exception Handling / Zero Overhead

exception table filled by the loader / linker traverse whole table for each stack frame system has default handler for uncatched

exceptions

no exceptions => no overhead exception case is expensive

system optimized for normal case

Run-Time Support Exception Handling / Fast Handling

try {.....

} catch (Exp1 e) {.....

} catch (Exp2 e) {.....

pchandler1

pchandler2

try {save (FP, SP, Exp1, pchandler1)save (FP, SP, Exp2, pchandler2).....remove catch descr.jump end

} catch (Exp1 e) {.....remove catch descr.jump end

} catch (Exp2 e) {.....remove catch descr.

jump end}end:

push catchdescriptors on

the stack

add codeinstrumentation

use an exception stack to

keep track of the handlers

void ExceptionHandler(ThreadState state){

int FP, SP, handler;Exception e;

do{retrieve(FP, SP, e, handler);

} while (!Match(state.exp, e));

state.fp = FP; // set frame to the onestate.sp = SP; // containing the handlerstate.pc = handler; // resume with the handlerResumeExecution(state)

pop next exception descriptor from exception stack

can resume in a different

activation frame

code instrumentation insert exception descriptor at try remove descriptor before catch

fast exception handling overhead even when no exceptions

system optimized for exception case

Virtual Addressing Overview

Virtual Addressing: abstraction of the MMU(Memory Management Unit)

Work with virtual addresses, whereaddressreal = f(addressvirtual)

Provides decoupling from real memory– virtual memory– demand paging– separated address spaces

Virtual AddressingPages

Memory as array of pages

virtual address-space 2

real memory:pool of page frames

virtual address-space 1

unmapped(invalid) page

pagepageframe

unmappedrange

mapping

programs use and run in this

address spaces

memory address

Translation Lookaside BufferAssociative Cache

(PT, VA, RA)(PT, VA, RA)(PT, VA, RA)

Virtual Address Real Address

page-no off

Virtual AddressingPage mapping

Page Table Ptr

Register

Virtual Address Real Addressframe

Real Memory

Page Frameframe

Page Table

page-no

Virtual AddressingDefinitions

page smallest unit in the virtual address space

page frame unit in the physical memory

page table table mapping pages into page frames

page fault access to a non-mapped page

working set pages a process is currently using

Virtual AddressingAlternate Page Mapping

Multilevel page tables Multipart Virtual Address Page table as (B*-)Tree

Inverted Page-Table

pno1 pno2 off

pr, vp pf

Next probe

Processpf

pfHashtable

64 bit Address Space

1. Level Table2. Level Table

unassigned

Virtual AddressingWhat for?

Decoupling from real memory– virtual memory (cheat: use more virtual memory than the

available real memory)– dynamically allocated contiguous memory blocks (for

multiple stacks in multitasking systems)– some optimizations

null reference checks garbage collection (using dirty flag)

Virtual Addressing is not for free!– address mapping may require additional memory accesses– page table takes space

Virtual AddressingVirtual Memory

Use secondary storage (disc) to keep currently unused pages (swapping)

Page table usually keeps some per-page flag invalid page not mapped referenced page has been referenced dirty page has been modified

Accessing an invalid page causes a page-fault interrupt select page frame to be swapped out (victim or candidate) swap-in requested page frame

Virtual AddressingVirtual Memory / Demand Paging

“Page-out”

“Page-in”Real Memory

Page Table

victimset to invalid

requestedpage

Virtual AddressingDemand Paging Sequence

ELSE Access Page Table; IF Page invalid THEN Page-Fault ELSE RETURN RA ENDEND

IF Free Page Frame exists THEN Assign frame to VAELSE Search victim page; IF victim page modified THEN page-out to secondary storage END; Invalidate victim page; Assign frame to VAEND;Page-in from secondary storage;Reset invalid flag

OSPage-Fault

Handler

IF VA IN TLB THEN RETURN RA

E[t] = PTLB * tTLB +PPT * tPT +Pdisc * tdisc

Expected time to translateVA into RA

Virtual Addressing Example

Page size 4 KBAddress size 32 Bits

addressable memory: 232 = 4GB

page offset: 12 Bits (4KB = 212)page number: 20 Bits (32 - 12)

page table size: 220 * 32 Bits = 4 MB

Real Memory 128 MB page table overhead: ca. 3%

Virtual Addressing Example

mov EAX, @Addr

1-PTLB

PageTable

TLBPTLB

DiscPpage

Memory1-Ppage

fault 1 disc read1 disc write

1 memory read

E[t] = PTLB tTLB + (1- PTLB)(tPT + PPF tdisc + (1-PPF)tmem)

Virtual AddressingDemand Paging: Page Replacement

Optimal Strategy (Longest Unused) Take the page, that will remain unused for the

longest time Requires oracle

Pref ref mod

NRU: ”Not Recently Used” Reset the referenced flag at each

tick Create page categories (good

candidate to bad candidate) choose best candidate

Virtual AddressingDemand Paging: Page Replacement (2)

LRU: “Least Recently Used” Assumption:

not used in past ==> not used in the future Hardware implementation

64-Bit time-stamp for each page Software implementation

“Aging”-Algorithm Choose page with lowest value

0 0 0 01 111 1 1

0 1 11

Reference Flag

t(i+1)

set if page accessed

“Least Recently Created” LRC (FIFO) Page Lifespan as metric (old are swapped out) Chain sorted by creation time Bad handling for often-used pages

Fix: “second chance” when accessed (ref flag set) during the last tick

earliest

Ref-Flag

cur := earliest;WHILE cur.ref DO cur.ref := FALSE; cur := cur.nextEND

Strategies:– optimal– LRU / NRU / LRC

Exceptions:– “page pinning”: page cannot be swapped out

kernel code

Virtual AddressingExample

Accessed Pages: 1, 2, 1, 3, 4, 1, 2, 3, 4Available Page Frames: 3

working set{1,2,3,4}

Page Access

1 2 1 3 4 1 2 3 4

Ideal 1 1, 2 1, 2 1, 2, 3 1, 2, 4 1, 2, 4 1, 2, 4 2, 3, 4 2, 3 ,4

FIFO 1 1, 2 1, 2 1, 2, 3 2, 3, 4 3, 4, 1 4, 1, 2 1, 2, 3 2, 3, 4

LRU 1 1, 2 1, 2 1, 2, 3 1, 3, 4 1, 3, 4 1, 4, 2 4, 2, 3 4, 2, 3

PF! PF! PF! PF! PF! PF! PF!

PF! PF! PF! PF!

PF! PF! PF! PF! PF!

Demand PagingBelady’s Anomaly

LRC Strategie• 3 Page Frames

9 Page Faults

• 4 Page Frames10 Page Faults

0 1 2 3 0 1 4 0 1 2 3 4

0 1 2 3 0 1 4 4 4 2 3 3 0 1 2 3 0 1 1 1 4 2 2 0 1 2 3 0 0 0 1 4 4

0 1 2 3 0 1x x x x x x x x x

0 1 2 3 3 3 4 0 1 2 3 4 0 1 2 2 2 3 4 0 1 2 3 0 1 1 1 2 3 4 0 1 2 0 0 0 1 2 3 4 0 1

0 1 2 3 4 0x x x x x x x x x x

Victim

Page access sequence

Belady’s Anomaly:More page frames cause more page faults

Demand PagingHow many page frames per process?

Even Distribution Every process has the same amount of memory Thrashing

every memory access causes a page-fault not enough page-frames for the current working-set

Process Count

CPU-Load

1 2 n n+1

System is swapping instead

of running

Demand PagingHow many page frames per process? (2)

Depending on the process needs (1) use Working-Set

Page Frames assigned according to the process’ working-set size. Swap-out a process when not enough memory available.

1 3 2 2 3 3 1 2 2 3 3 3 4 2 2 1 1 1 2 1 3 3 3 1 3 1 2 3 4 1

{ 1, 2, 3, 4 }Sliding

Window

Page Access

{ 2, 3, 4 }Working

Demand PagingHow many page frames per process? (3)

Depending on the process needs (2) use Page-Fault Rate

Page-Fault Rate

Swap out one process Swap in

Virtual AddressingAos/Bluebottle, Memory Layout Example

Stacks

Kernel

PROCEDURE PageFault;BEGIN

IF adr > 2GB THENadd page to stack

ELSEException(NilTrap)

ENDEND PageFault;

• 128 KB per stack• max. 32768 active objects• first stack page allocated on process creation

Virtual AddressingExample: UNIX, Fork

a UNIX Program consists of.....

Process B

Fork()read-only

read-only

Process A

read-only

Page Table

data’read-write“copy on write”

Virtual AddressingOS Control

Oberon– no virtual memory

Windows– Virtual Memory configuration– Task Manager

Linux– Swap partition / Swap files– ps / top

Virtual AddressingSegmentation

e.g. Intel x86 Problem

– 640KB Max Memory– 16bit addresses (i.e. 64KB)

Solution– work in a segment– code / data segments– check segment boundaries

Addrreal = Segbase+Offset

real memory

datasegment

codesegment

segment limit

segment base

Virtual AddressingSummary

virtual addresses, addressreal = f(addressvirtual)

Decoupling from real memory– virtual memory– demand paging– separate address spaces

Keywords– page– page frame– page table– page fault– page flags

dirty, used, unmapped

– page replacement strategy LRC, LRU, ideal, ...

– swapping– thrashing, belady’s anomaly

Memory ManagementOverview

Abstractions for applications

– heap– memory blocks

( << memory pages)

Operations:– Allocate– Deallocate

Topics:– memory organization– free lists– allocation strategies– deallocation explicit– garbage collection

type-aware conservative copying / moving incremental generational

Memory ManagementObjects on the heap

Object Instances: a, b, c, d, … Sequence:

NEW(a)NEW(b)NEW(c)DISPOSE(b)NEW(d)NEW(e)

dynamicallocation

explicitdisposal

„Heap“

Case 1

Case 2

not enough space

Memory ManagementProblem overview

Problems Heap size limitation ( e, case 1) External Fragmentation ( e, case 2) Dangling Pointers (a points to b)

Solutions System-managed list of free blocks

(„free list“) Vector of blocks with fixed size

(Bitmap, with 0=free, 1=used) Automated detection and reclamation of unused blocks

(„garbage collection“)

Memory ManagementTheory: 50% rule

Assumption: stable state M free blocks, N block allocated 50%-Rule: M = 1/2 N

A B B B BC C

N = A + B + CM = 1/2 (2A + B + e) e = 0,1, or 2

block disposal: ΔM = (C - A) / Nblock allocation:(splitting likelihood)

ΔM = 1 - p

(C - A) / N = 1 - pC - A - N + pN = 0

2M = 2A + B + e2M = 2A + N - A - C + e2M = N + A - C + e

2M +e = pN

Memory ManagementTheory: Memory Fragmentation

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

{ 50%-Rule }(b/2)*F = H - b*B, /2*b*B = H - b*BH/(b*B) = 1 + /2, = 2/ - 2

Criticalpoint

Memory ManagementFree-list management with a Bitmap

Idea– partition heap in blocks of size s– use bitmap to track allocated blocks

bitmap[i] = true blocki allocated Problems

– internal fragmentationround up block size to next multiple of s

– map sizesize is (heap_size / s) bits

loss due to internal

fragmentation

Memory ManagementFree-list management with a list

List organization– sorted / non-sorted

merging of empty blocks is simpler with sorted list– one list / many lists (per size)

search is simpler, merging is more difficult– management data stored in the free block

size, next pointer

Operations– Allocation– Disposal with merge

find free blocks next to current block, merge into bigger free block

Memory ManagementMemory allocation strategies

block splitting:– if a free-block is bigger than the requested block, then it is split

first-fit– use first free block which is big enough

best-fit– take smallest fitting block causes a lot of fragmentation

worst-fit– take biggest available block

quick-fit– best-fit but multiple free-lists (one per block size) fast allocation!

freeused used freeused usedused

usedused used

internal fragmentation

Memory ManagementBuddy System (for fast block merging)

Blocks have size 2k

Block with size 2i has address j*2i (last i bits are 0)

Blocks with address x=j*2i and (j XOR 1)*2i are buddies (can be merged into a block of size 2i+1)

buddy = x XOR 2i

321616

32816 8b1 xxxx 0 0000b2 xxxx 1 00002k+1

2k-1Merge

Problem: only buddies can be merged

Cascading merge

321616

32816 8

321616

32816 8

no buddiesbuddies

32816 8

321616

Allocation– allocate(8)

328 168

321616

3232split

quickfit

328 168

Block size = k*32free-lists for k = 1..9, one list for blocks > 9*32

Allocate quick-fit, splitting may be required Free-list management and block-merging done

by the Garbage Collector

Memory ManagementExample: Oberon / Aos

k * 32966432

ALLOCATE(50)

initialstate

k * 32966432

Allocated Block

Memory ManagementGarbage Collection

Two steps:

1. Free block detection– type-aware

collector is aware of the types traversed, i.e. know which values are pointers

– conservative collector doesn’t know

which values are pointers

2. Block Disposal return unused blocks to the

free-lists

GC Characteristics– incremental

gc is performed in small steps to minimize program interruption

– moving / copying / compactingblocks are moved around

– generationalblocks are grouped in generations; different treatment or collection priority

Barriers– read

intercept and check every pointer read operation

– writeintercept and check every pointer write operation

Memory ManagementGarbage Collection: Reference Counting

Every object has a Reference counter rc rc = 0 Object is „Garbage“ Problems

Overhead

no support for circular structures

Useful for... Module hierarchies DAG-Structures (z. B. LISP)

p, q Pointers to Objectq := p

write barrier

INC p.rcDEC q.rcIF q.rc = 0 THEN Collect q^END;q := p

rc >= 1

Memory ManagementGarbage Collection: Mark & Sweep

Mark-Phase (Garbage Detection) Compute the Root-set consisting of

global pointers (statics) in each module local pointers on the stack in each PAF temporary pointers in the CPU’s registers

Traverse the graph of the live objects starting from the root-set with depth-first strategy; mark all reached objects.

Sweep-Phase (Garbage Collection) Linear heap traversal. Non-marked blocks are inserted into

free-lists. Optimization: lazy sweeping (sweep during allocation,

allocation gets slower)

Run-time support from object-system. Hidden data structures with (compiler generated) information about pointers (metadata).

Conservative approach. Guess which values could be pointers and threat them as such

Memory ManagementGarbage Collection: root-set

off2off1

ModuleDescriptor

ModuleData

ObjectInstance

TypDescriptor

Type Tag

globalpointer

instance

pointer

Memory ManagementGarbage Collection: Mark with Pointer Rotation/1

Problem:Garbage collection called when free memory is low, but mark may require a lot of memory

Solution:Pointer rotation algorithm (Deutsch, Schorre , Waite)

+ Memory efficient+ iterative

– structures are temporarily inconsistent– non-concurrent– non-incremental

q pq p

p.link

Simple case: list traversal

Generic case: structure traversal

Memory ManagementGarbage Collection: Memory Compaction

nextavail Pointer: partition heap between allocated and free space

Allocate: increment nextavail Garbace Collector performs memory compaction

nextavail

MS .NET

Memory ManagementGarbage Collection: Stop & Copy

Partition heap in from and to regions Collection:

– traverse objects in from, copy to to– leave forwarding pointer behind– requires read barrier– swap from and to

Characteristics– copying– incremental– (generational)

IF p is moved THENreplace p with forwarding pointer

END;access p

access p

instrument code with read barrier

Memory ManagementGarbage Collection: Stop & Copy

from to

to from

Memory ManagementGarbage Collection: Concurrent GC

„Stop-and-Go“ Approach

„Incremental“ Approach

Mutator Mutator MutatorGC GC

Mutator

Mutator Mutator Mutator

User Process

Real-TimeConstraint

Memory ManagementGarbage Collection: Tricolor marking

„Wave-front“ Model

State Color

already traversed,behind wave

being traversed,on the wave

not reached yet,

in front of the wave

Mutator can change pointers at any time Critical case: black white

Remedy Write-Barrier

color B gray color W gray

Memory ManagementGarbage Collection: Tricolor marking / Isolation

unreachable

WriteBarrier

Memory ManagementGarbage Collection: Backer‘s Treadmill

To-SpaceFrom-Space

Free-Space

Heap: double-linked chain of

objects

curscan

To-Space From-Space

Free-Space

curscan

conservativeallocation

progressiveallocation

collect

To-SpaceFrom-Space

Free-Space

curscan

reference

curscancurscan

State transitions after GC is complete From-Space + Free-Space Free-Space ToSpace FromSpace

Fragmentation External: not removed Internal: depends on

supported block sizes Allocation

conservative: black progressive: white

Root Set

NEW(y)

NEW(x)

curscan

Memory ManagementGenerational Garbage Collection

Generations Expected object life

young short life (temp data)old long life

Generations G0, G1, G2

G0 special handling for pointers

across different generations

required

frequency

G0 high

G1 medium

G2 low

collect where it is garbage is most

likely to be found

Memory ManagementGarbage Collection: Finalization

Finalization (after-use cleanup) User-defined routine when object is collected Establish Consistency

save buffers flush caches

Release Resources close connections release file descriptors

Dangers: Resurrection of objects: objects added to live structures Finalization sequence is undefined

Memory ManagementGarbage Collection: .NET Finalization Example

Rules:objects with finalizer belong to

older generation finalizer only called once

(ReRegisterForFinalize)FinalizationQueue: live object

with finalizerFreachableQueue: collected

objects to be finalizedFinalization executed by

different process for security reasons

ABCDE E

garbageFinalizationQueue

A FinalizationQueue

FreachableQueue

thread

Memory ManagementGarbage Collection: Weak Pointers

„Weak“ Pointers Objects referenced only

through a weak pointer can be collected by the GC in case of need

Used for Caches and Buffers

Implementation1. Weak Pointers are not

registered to the GC

2. Use a weak reference table (indirect access)

garbagegarbage in use

weak pointer

weak reference

weak reference table

Memory ManagementGarbage Collection: Weak Pointers Example

Oberon: internal file list– system must keep track of open files to avoid buffer

duplication– file descriptor must be collected once user has no

more reference to it– use weak pointer in the system (otherwise would

keep file alive!)

Memory ManagementObject Pools

Application keeps a pool of preallocated object instances; handles allocation and disposal Simulation discrete events Buffers in a file system Provide dynamic allocation in real-time systemPROCEDURE NewT (VAR p: ObjectT);BEGIN IF freeT = NIL THEN NEW(p) ELSE p := freeT; freeT := freeT.next ENDEND NewT;

PROCEDURE DisposeT (p: ObjectT);BEGIN p.next := freeT; freeT := pEND DisposeT;

Garbage Collection, Recap

GC kinds: compacting copying incremental generationalHelpers: write barrier read barrier forwarding pointer pointer rotation

Algorithms: Ref-Count Mark & Sweep Stop & Copy Mark & Copy (.NET) Baker’s Threadmill

– Dijkstra / Lamport– Steele

Distributed Object SystemsOverview

Goals– object-based approach– hide communication

details

Advantages– more space– more CPU– redundancy– locality

Problems Coherency

– ensure that same object definition is used

Interoperability– serialization– type consistency– type mapping

Object life-time– distributed garbage collection

Distributed Object SystemsArchitecture

Proxy Stub Impl.

NamingService

ObjectBroker

Client Server

ObjectBroker

CallContex

tMessage

IDL-Compiler IDL-Compiler

Impl.Skeleton

Application

Remote Procedure InvocationOverview

Problem– send structured

information from A to B– A and B may have

different memory layouts– “endianness”

– How is 0x1234 (2 bytes) representend in memory?

12 340 1

Big-Endian: MSB before LSB• IBM, Motorola, Sparc

Little-Endian: LSB before MSB•VAX, Intel

network byte-ordering

little end first

Definitions

Serialization– conversion of an object‘s instance into a byte stream

Deserialization– conversion of a stream of bytes into an object‘s instance

Marshaling– gathering and conversion (may require serialization) to an

appropriate format of all relevant data, e.g in a remote method call; includes details like name representation.

Remote Procedure InvocationProtocol Overview

Protocols– RPC + XDR (Sun)

RFC 1014, June 1987 RFC 1057, June 1988

– IIOP / CORBA (OMG) V2.0, February 1997 V3.0, August 2002

– SOAP / XML (W3C) V1.1, May 2000

– ...

XDR Type System– [unsigned] Integer (32-bit)– [unsigned] Hyper-Integer (64-bit)– Enumeration (unsigned int)– Boolean (Enum)– Float / Double (IEEE 32/64-bit)– Opaque– String– Array (fix + variable size)– Structure– Union– Void

big-endian representation

Remote Procedure InvocationRPC Protocol

Remote Procedure Call Marshalling of procedure

parameters

Message Format Authentication Naming

Client

PROCEDURE P(a, b, c)• pack parameters• send message to

server• await response• unpack response

Server

Server• unpack parameters• find procedure• invoke• pack response• send response

P(a, b, c)

Distributed Object SystemsDetails

References vs. Values– client receives reference to

remote object– data values are copied to

client for efficiency reasons– decide whether an object is

sent as reference or a value serializable (Java, .NET),

valuetype (CORBA) MarshalByRefObject (.NET),

java/RMI/Remote (Java), default (CORBA)

object creation– server creates objects– client creates objects– server can return references

object instances– one object for all requests– one object for each requests– one object per proxy

conversation state– stateless– stateful

Distributed Object SystemsDistr. Object Systems vs. Service Architecture

Dist. Object System– object oriented model– object references– stateful / stateless– tight coupling

Service Architecture– OO-model / RPC– service references– stateless– loose coupling

internal communication between application’s

external communication

between applications

Distributed Object SystemsDistr. Object Systems vs. Service Architecture

heterogeneoushomogeneous

tightloose

CORBAR

emoting

Web Services

• components / objects(distributed object system)

• stateful and statelessconversation

• transactions

• servicesremote procedure calls

• stateless conversation(session?)

• messageenvironment

coupling

Distributed Object SystemsType Mapping

Type System 1InteroperabilityType System Type System 2

Possible Types Possible Types Possible Types

MappableTypes

InteropSubset

Distributed Object SystemsType Mapping, Example

JavaType System

CORBAType System

CLSType System

doubledouble double

enumenum

union union union

custom implementation custom implementation

Distributed Object SystemsExamples

Standards– OMG CORBA

– Web Services SOAP

Frameworks– Java RMI (Sun)– DCOM (Microsoft)– .NET Remoting (Microsoft)

IIOP.NET

Distributed Object SystemsCORBA

Common Object Request Broker Architecture

TCP/IP Socket

ORBORB

InterfaceRepository

ImplementationRepositoryCORBA

Runtime

Object AdaptorCORBARuntime

Client StubObject Skeleton

ObjectClient Application

Remote Architecture

Client Server

GIOP/IIOP

„Object-Bus“

– CORBA is a standard from OMG

Object Management Group Common Object Request

Broker Architecture

– CORBA is useful for... building distributed object

systems heterogeneous

environments tight integration

– CORBA defines... an object-oriented type system an interface definition language

(IDL) an object request broker (ORB) an inter-orb protocol (IIOP) to

serialize data and marshall method invocations

language mappings from Java, C++, Ada, COBOL, Smalltalk, Lisp, Phyton

... and many additional standards and interfaces for distributed security, transactions, ...

Basic Types– integers

16-, 32-, 64bit integers (signed and unsigned)

– IEEE floating point 32-, 64-bit and extended-

precision numbers– fixed point– char, string

8bit and wide– boolean– opaque (8bit), any– enumerations

Compound Types– struct– union– sequence (variable-length array)– array (fixed-length)– interface

concrete (pass-by-reference) abstract (pure definition)

– value type pass-by-value abstract (no state)

Operations in / out / inout parameters raises

Attributes

Distributed Object SystemsCORBA / General Inter-ORB Protocol (GIOP)

CDR (Common Data Representation)

– Variable byte ordering– Aligned primitive types– All CORBA Types supported

IIOP (Internet IOP)– GIOP over TCP/IP– Defines Interoperable Object

Reference (IOR) host post key

Message Format– Defined in IDL– Messages

Request, Reply CancelRequest, CancelReply LocateRequest, LocateReply CloseConnection MessageError Fragment

– Byte ordering flag– Connection Management

request multiplexing asymmetrical / bidirectional

connections

Distributed Object SystemsCORBA / GIOP Message in IDL

module GIOP {struct Version {

octet major;octet minor;

}enum MsgType_1_0 {

Request, Reply, CancelRequest,CancelReply, LocateRequest,LocateReply, CloseConnection, Error

struct MessageHeader {

char Magic[4];

Version GIOP_Version;

boolean byte_order;

octet message_size;

unsigned long message_type;

} // module end GIOP

Distributed Object SystemsCORBA Services

CORBA Services– System-level services defined

in IDL– Provide functionality required by

most applications Naming Service

– Allows local or remote objects to be located by name

– Given a name, returns an object reference

– Hierarchical directory-like naming tree

– Allows getting initial reference of object

Event Service– Allows objects to

dynamically register interest in an event

– Object will be notified when event occurs

– Push and pull models ... and more

– Trader, LifeCycle, Persistence, Transaction, Security

Web Services

Distributed Object SystemsWebServices

Service-oriented architecture Rely on existing protocols

– SOAP messaging protocol

– WSDL service description protocol

– UDDI service location protocol

TCP/IP

Distributed Object SystemsSOAP

Simple Object Access Protocol communication protocol XML-based describes object values XML Schemas as interface

description language– basic types

string, boolean, decimal, float, double, duration, datetime, time, date, hexBinary, base64Binary, URI, Qname, NOTATION

– structured types list, union

SOAP Message– SOAP Envelope– SOAP Header– SOAP Body

Method Call– packed as structure– messages are self-

contained– no external object

references

Distributed Object SystemsSOAP Message

SOAP Message– SOAP Envelope

SOAP Header SOAP Body

Example

float Multiply(float a, float b);

Distributed Object SystemsSOAP Example (Request)

POST /quickstart/aspplus/samples/services/MathService/CS/MathService.asmx HTTP/1.1

Host: samples.gotdotnet.com Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: "http://tempuri.org/Multiply" <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body>

<Multiply xmlns="http://tempuri.org/"> <a>float</a> <b>float</b> </Multiply></soap:Body>

</soap:Envelope>

Distributed Object SystemsSOAP Example (Answer)

HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: length <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-

instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body>

<MultiplyResponse xmlns="http://tempuri.org/"> <MultiplyResult>float</MultiplyResult>

</MultiplyResponse> </soap:Body>

</soap:Envelope>

Distributed Object SystemsSOAP Example (Service Description-1)

<?xml version="1.0" encoding="utf-8"?><definitions ....> <types> <s:schema elementFormDefault="qualified"

targetNamespace="http://tempuri.org/"> <s:element name="Multiply"> <s:complexType><s:sequence> <s:element minOccurs="1" maxOccurs="1" name="a" type="s:float" /> <s:element minOccurs="1" maxOccurs="1" name="b" type="s:float" /> </s:sequence></s:complexType> </s:element> </s:schema> </types> <message name="MultiplySoapIn"> <part name="parameters" element="s0:Multiply" /> </message>

Distributed Object SystemsSOAP Example (Service Description-2)

<binding name="MathServiceSoap" type="s0:MathServiceSoap"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http"

style="document" /> <operation name="Multiply"> <soap:operation soapAction="http://tempuri.org/Multiply" style="document" /> <input><soap:body use="literal" /></input> <output><soap:body use="literal" /></output> </operation> </binding> <service name="MathService"> <port name="MathServiceSoap" binding="s0:MathServiceSoap"> <soap:address

location="http://samples.gotdotnet.com/quickstart/aspplus/samples/services/MathService/CS/MathService.asmx" />

</port> </service></definitions>

Distributed Object SystemsWebServices

Comments– XML (easily readable)– system independent– standard– stateless (encouraged design

pattern)

– bloated– big messages (but easily

compressed)– requires expensive parsing

Constraints– Services

no object references server-activated servant

– Goes over HTTP requires web server

Distributed Object SystemsWebService Future

Use SOAP-Header to store additional information about message or context

Many standards to come...– WS-Security– WS-Policy– WS-SecurityPolicy– WS-Trust– WS-SecureConversation– WS-Addressing

Distributed Object SystemsJava RMI

Java Remote Method Invocation

TCP/IP Socket

TransportLayer

RemoteReferences

Object Stub

Network

Remote Architecture

Client Server

LookupRegister

TransportLayer

RemoteReferences

Object Stub

LookupRegister

Distributed Object SystemsJava RMI Details

Framework– supports various implementations

e.g. RMI/IIOP– mapping limited to the Java type system, workarounds

needed

– uses reflection to inspect objects

Distributed Object-SystemsLow-Level Details: Java RMI/IIOP

Common Type-System– restricted CORBA

Marshalling– name mapping– remote objects

only references

Interface Description Language (IDL)

– java to IDL mapping

Message representation Underlying protocol

– IIOP (CORBA)

Distributed Object SystemsMicrosoft DCOM

Distributed Common Object Model

RPC Channel

SCMSCM

SCMs and RegistrationCOMRuntime

COMRuntime

Object Proxy Object Stub

Network

Remote Architecture

Client ServerRegistry Registry

OXID Resolver

Ping Server

Distributed Object SystemsMicrosoft .NET Remoting

InstanceInstance

Network

ChannelChannelChannelChannel

TransparentProxy

ObjRefObjRef

ClientClient

new Instace()or

Activator.GetObject(...) Application D

omain B

oundaryIChannelInfo ChannelInfo;IEnvoyInfo EnvoyInfo;IRemotingTypeInfo TypeInfo;string URI;

channel

ClientClient InstanceInstance

Instance s = new Instance();s.DoSomething();

Network

ProxyProxy DispatcherDispatcher

FormatterFormatter FormatterFormatter serialize object

TransportSink

handle communication

Stream Chan.Sink(s)

custom operations

MessageChan.Sink(s)

custom operations

Activation client

– one instance per activation server / Singleton

– one instance of object server / SingleCall

– one instance per call

Leases (Object Lifetimes)– renew lease on call– set maximal object lifetime

Serialization– SOAP

Warning: non-standard types, only for .NET use

– binary– user defined

Transport– TCP– HTTP– user defined

AppDomain 2AppDomain 1

Distributed Object SystemsMicrosoft .NET Remoting (Object Marshalling)

MarshalByRefObjects remoted by reference client receives an ObjRef

object, which is a“pointer“ to the original object

[Serializable] all fields of instance are

cloned to the client [NonSerialized] fields are

ignored ISerializable

object has method to define own serialization

Obj Proxy

AppDomain 2AppDomain 1

Obj Obj‘

SerializedObjRef

Serializedfld1... fldn

Distributed Object SystemsMicrosoft .NET Remoting, Activation

Server-Side Activation (Well-Known Objects)

– Singleton Objects only one instance is allocated to process all

requests– SingleCall Objects

one instance per call is allocated

Client-Side Activation– Client Activated Objects

the client allocates and controls the object on the server

“stateless”

“stateful”

Distributed Object SystemsMicrosoft .NET Remoting, Limitations

–Server-Activated Objects object configuration limited to the default constructor

–Client-Activated Objects class must be instantiated, no access over interface class hierarchy limitations use Factory Pattern

– to get interface reference– to allow parametrization of the constructor

–Furthermore... interface information is lost when passing an object reference to another

machine no control over the channel

– which channel is used– which peer is allowed to connect

Distributed Object SystemsCase Study: IIOP.NET

Opensource project based on ETH-Diploma thesis– http://iiop-net.sourceforge.net/

IIOP.NET (marketing)– „Provide seamless interoperability between .NET and CORBA-

based peers (including J2EE)“

IIOP.NET (technical) .NET remoting channel implementing the CORBA IIOP protocol Compiler to make .NET stubs from IDL definitions IDL definition generator from .NET metadata

IIOP rather than SOAP transparent reuse of

existing servers tight coupling object-level granularity efficiency

Runtime: standard .NET remoting channel for IIOP transport sink formatter type-mapper

Build tools IDL CLS compiler CLS IDL generator

.NETserver

.NETclient

J2EEserver

Javaclient

CORBAobjects

IIOPbinary IIOP

Java Type System IDL Type System CLS Type System

Possible Types Possible Types Possible Types

IDL MappableTypes

IDLMappableTypesInterop

Subset

Distributed Object SystemsCase Study: IIOP.NET, Interoperability

CommunicationProtocols

Data Model

Message Format

Contextual DataInterception Layer

Conversation

Services

Application

TCP/UDP, Byte stream, point-to-point communication

Type system, mapping and conversion issues

RPC, IIOP, HTTP, SOAP, proprietary binary format,messages, unknown data (exceptions), encryption

SessionID, TransactionID, cultureID, logical threadID …

Activation model (EJB, MBR), global naming,distributed garbage collection, conversational state,…

Distributed Transaction Coordinator, Active Directory, …

This is what we want

Distributed Object SystemsCase Study: IIOP.NET, Granularity

Service Component Object

Message-basedInterface,Stateless

Strongly-typedInterface,

Stateless or Stateful

ImplementationDependency,

Stateful

Object Object

Component

Object Object

Component

Object Object

Component

Service Service

System

Granularity

Coupling,Interaction

1.01.11.2

Distributed Object SystemsCase Study: IIOP.NET, Performance

Test Case:–WebSphere 5.0.1 as server–Clients

IBM SOAP-RPC Web Services IBM Java RMI/IIOP IIOP.NET

–Response time receiving 100 beans from

server– WS: 4.0

seconds– IIOP.NET: 0.5

seconds when sending many more

beans, WS are then 200% slower than IIOP.NET

Source: posted on IIOP.NET forum

Processes and ThreadsIntroduction

CPU as resource, provide abstraction to it

Allow multiprogramming– pseudo-parallelism

(single-processors)– real parallelism

(multi-processors)Required abstractions

– multiple activities -- execution of instructions

– protection of resources– synchronization of activities

Topics– coroutines– processes – threads– scheduling

fairness starvation

– synchronization deadlocks

Processes and ThreadsMultithreading

Call a.run Call b.Q Call b.q Call b.q Return b.q Return b.q Call c.R Return c.R Return b.QReturn a.run

Thread 1 b.q

Call c.run Call d.Q Call d.q Call d.q Return d.q Return d.q Call e.R Return e.R Return d.QReturn c.run

Thread 2

Stack 1

Stack 2

time12

Processes and ThreadsCoroutines (1)

Coroutines– each activity has its own stack, address-space is

shared– explicit context switch (stack only) under

programmer‘s control– uses Transfer call switch to another coroutine

Subroutines

Coroutinen

Return

Transfer

Return

TYPE Coroutine = POINTER TO RECORDFP: LONGINT;stack: POINTER TO ARRAY OF SYSTEM.BYTE;

VAR cur: Coroutine; (* Current Coroutine *)

PROCEDURE Transfer*(to: Coroutine);BEGIN

SYSTEM.GETREG(SYSTEM.EBP, cur.FP);cur := to;SYSTEM.PUTREG(SYSTEM.EBP, cur.FP);

END Transfer;

MOV ESP, EBPPOP EBPRET 4

PUSH EBPSUB ESP, 4

save FP

restore FP

to’SPFP

PC’FP’

locals

stackQstackP

FP PC’FP’

locals

stackQstackP

localsFP”

FP := Q.FP

FP PC’FP’

locals

stackQstackP

localsFP”

Transfer(Q)

stackQstackP

localsFP”

returnjump at PC’

Current stack: current execution state All other stacks: top PAF (proc activation frame) contains last

Transfer call Start: create stack with fake Transfer-like PAF

PROCEDURE Start(C: Coroutine; size: LONGINT);BEGIN

NEW(C.stack, size);tos := SYSTEM.ADR(C.stack[0])+LEN(C.stack);SYSTEM.PUT(tos-4, 0); (* par = null *)SYSTEM.PUT(tos-8, 0); (* PC’ = null, not allowed to return *)SYSTEM.PUT(tos-12, 0); (* FP’ *)cur.FP := tos-12;

Processes and ThreadsProblems caused by multitasking

Concurrent access to resources

– protectionlimit access to a resource

– synchronizationsynchronize task with resource state or other task

Concurrent access to CPU– task priorities– scheduling

One problem’s solution is another problem’s cause....

– deadlocks– fairness– deadlines / periodicity

constraints

Processes and ThreadsProtection: Mutual Exclusion

Mutual Exclusiononly one activity is allowed to access one resource at a time disable interrupts (single CPU only, avoid switches) locks

flag: lock taken / lock free spin lock (uses busy waiting) exclusive lock read-write lock (multiple reader, one writers)

Processes and ThreadsProtection: Monitor

Shared resources as Monitor resources are passive objects execution of critical sections inside monitor is

mutually exclusive Global Monitor Lock Shared Monitor Lock for read-access (optional)

monitor as a special module [original version (Hoare, Brinch Hansen)]

object instance as monitor method and code block granularity Java, C#, Active Oberon, ...

Resource

task P task Q

acquire

releaseacquire

release

Processes and ThreadsProtection

Simplistic implementation with coroutinesNon-reentrant lock (no recursion allowed)

PROCEDURE Acquire(r: Resource);BEGIN

IF r.taken THENInsertList(r.waiting, cur);SwitchToNextRoutine()

ELSEr.taken := TRUE

ENDEND Acquire;

PROCEDURE Release(r: Resource);BEGIN

next := GetFromList(r.waiting);IF next # NIL THEN

InsertList(ready , next);Transfer(GetNextTask());

ELSEr.taken := FALSE

ENDEND Release;

one waiting queue per resource is

required

Shared resource as Process synchronization during communication Communicating Sequential Processes (CSP)

C.A.R. Hoare (1978) Model of communication

„Rendez-vous“ between two processes P!x (send x to process P) Q?y (ask y from process Q)

Used in Ada, Occam

task P task Q

task P task QQ!z

Some variations on the theme....– Reentrant Locks– Readers / Writers

one writer or multiple readers allowed

– Binary Semaphores one activity can get the resource

– Generic Semaphores N activities are allowed to get the resource

Processes and ThreadsSynchronization

Wait on a condition / state Signals with Send/Wait Methods

Require cooperation from all processes

Example: Producer/Consumer with conditions nonempty/nonfull

Semantic of Send

Send-and-Pass vs. Send-and-Continue

Generic system-handled conditions (Active Oberon) AWAIT(x > y);

Wait on partner process CSP

Processes and ThreadsSynchronization: Implementation Example

Process list double-chained list of all coroutines cur points to current (running) coroutine each signal has a LIFO list

Signal cur

Scheduleprev := cur;WHILE ~cur.ready & cur.next # prev DO cur := cur.nextEND;IF cur.ready THEN Transfer(cur) ELSE (*deadlock*) END

Terminatecur.next.prev := cur.prev;cur.prev.next := cur.next;Schedule

Send(s)IF s # NIL THEN (*send-and-pass*) cur := s; s.ready := TRUE; s := s.linkEND;Schedule (*to next ready from cur*)

Wait(s)cur.link := s; s := cur; cur.ready := FALSE;Schedule (*to next ready from cur*)

Init(s)s := NIL

Processes and ThreadsActive Oberon: Bounded Buffer

Buffer* = OBJECTVAR

data: ARRAY BufLen OF INTEGER;in, out: LONGINT;

(* Put - insert element into the buffer *)

PROCEDURE Put* (i: INTEGER);BEGIN {EXCLUSIVE}

(*AWAIT ~full *)AWAIT ((in + 1) MOD BufLen #

out);data[in] := i; in := (in + 1) MOD

BufLenEND Put;

(* Get - get element from the buffer *)PROCEDURE Get* (VAR i: INTEGER);

BEGIN {EXCLUSIVE}(*AWAIT ~empty *)AWAIT (in # out);i := data[out]; out := (out + 1) MOD

BufLenEND Get;

PROCEDURE & Init;BEGIN

in := 0; out := 0;END Init;

END Buffer;

Processes and ThreadsCSP: Bounded Buffer (I)

[bounded_buffer || producer || consumer]

producer ::

*[<produce item>

bounded_buffer ! item;

consumer ::

*[bounded_buffer ? item;

Geoff CoulsonLancaster University

Processes and ThreadsCSP: Bounded Buffer (II)

bounded_buffer ::

buffer: (0..9) item;in, out: integer;

in := 0; out := 0;*[

in < out+10; producer ? buffer(in mod 10)-> in := in + 1;

||out < in; consumer ! buffer(out mod 10)-> out := out + 1;

Processes and ThreadsProcess State

Process states1. Running: actually using the

2. Ready: waiting for a CPU

3. Blocked: unable to run, waiting for external event

– Process state transitions1. wait for external event

2. system scheduler

3. system scheduler

4. external event happens

Running

Blocked Ready

Processes and ThreadsProcess State (Active Oberon)

Active Oberon provides– monitor-like object

protection– conditions

Condition are checked by the system.

No explicit help or knowledge from user is required (no x.Signal)

Running

AwaitingObject

AwaitingCondition

System-Software WS 04/05174 © P. Reali / M. Corti

Activities Program (static concept) ≠ Process (dynamic) Processes, jobs, tasks, threads (differences later)

– program code– context:

program counter (PC) and registersstack pointerstate

– [new]– running– waiting– ready– [terminated]

– stack– data section (heap)

Processes vs. Threads

Process or job (heavyweight)

– code– address space– processor state– private data

(stack+registers)

– can have multiple threads

Thread (lightweight)– shared code– shared address space– processor state– private data

(stack+registers)

Kernel

Processes vs. Threads: Example

PROC 1

PROC 2

HEAP 1

STACK 1

HEAP 2

STACK 2

STACK 1 STACK 2

Programmed events that can cause a task switch– protection (locks)

acquire release

– synchronization wait on a condition send a signal (send-and-pass)

System events that can cause a task switch– voluntary switch (“yield”, task termination)– process with higher priority becomes available– consumption of the allowed time quantum

task preemption

Multitasking

Preemption

Assign each process a time-quantum (normally in the order of tens of ms)

Asynchronous task switches can happen at any time!– task can be in the middle of a computation– save whole CPU state (registers, flags, ...)

Perform switch– on resource conflict– on synchronization request– on timer-interrupt (time-quantum is over)

Context switch Scheduler invocation:

– preemption interrupt– cooperation explicit call

Operations:– store the process state (PC, regs, …)– choose the next process (strategy)– [accounting]– restore the state of the next process (regs, SP, PC, …)– jump to the restored PC

A context switch is usually expensive: 1–1000s depending on the system and number of processes

– hardware optimizations (e.g., multiple sets of registers – SPARC, DECSYSTEM-20)

Scheduling algorithms

Three categories of environments: batch systems (e.g., VPP, DOS)

– usually non-preemptive (i.e., task is not stopped by scheduler, only synchronous switches)

interactive systems (UNIX, Windows, Mac OS)– cooperative or preemptive– no task allowed to have the CPU forever

real-time systems (PathWorks, RT Linux)– timing constraints (deadlines, periodicity)

Scheduling Performance CPU utilization Throughput

– number of jobs per time unit– minimize context switch penalty

Turnaround time– = exit time - arrival time– execution, wait, I/O

Response time– = start time - request time

Waiting time (I/O, waiting, …) Fairness

Scheduling algorithm goals

All systems– Fairness

give every task a chance

– Policy enforcement– Balance

keep all subsystems busy

Interactive systems– Response time

respond quickly

– Proportionality meet user’s expectations

Batch systems– Throughput

maximize number of jobs

– Turnaround time minimize time in system

– CPU utilization keep CPU busy

Real-time systems– Meet deadlines

avoid losing data

– Predictability avoid degradation

– Hard- vs. soft-real-time systems

Batch Scheduling Algorithms

Choose task to run (task is usually not preempted) First Come First Serve (FCFS)

– fair, may cause long waiting times

Shortest Job First (SJF)– requires knowledge about job length

Longest Response Ratio– response ratio = (time in the system / CPU time)– depends on the waiting time

Highest Priority First– with or without preemption

Mixed– the priority is adjusted dynamically (time in queue, length, priority, …)

ETH-VPP is a batch system!

Which algorithm does it use?

Time sharing– Each task has a predefined time quantum– Round-Robin

Schedule next task on the ready list

– Quantum choice:small: may cause frequent switchesbig: may cause slow response

– Implicit assumption: all task have same importance

Preemptive Scheduling Algorithms

Priority scheduling– process with highest priority is scheduled first

Variants– multilevel queue scheduling

one list per priority, use round-robin on list– dynamic priorities

proportional to time in system inversely proportional to part of quantum used

– make time quantum proportional to priority

Real-Time Scheduling Algorithms

Task needs to meet the deadline!

Task cost is known (should)

Two task kind:– aperiodic– periodic

Reservation– scheduler decides if

system has enough resources for the task

Algorithms:– Rate Monotonic

Schedulingassign static priorities (priority proportional to frequency)

– Earliest Deadline Firsttask with closest deadline is chosen

Scheduling Algorithm Example Situation:

– Tasks P1, P2, P3, P4 Arrive at time t = 0 Priority: P1 highest, P4 lowest Time to process: 10, 2, 5, 3

P40 10 12 17 20

Scheduling Algorithm Example Highest Priority First

P40 2 20105

Scheduling Algorithm Example Shortest Job First

P40 2 4 6 8 10 12

1314 16 18 20

Scheduling Algorithm Example Timesharing with quantum = 2

P40 8 11 15 20

runningat 1/4

runningat 1/3

runningat 1/2

Scheduling Algorithm Example Timesharing with quantum 0

Scheduling Algorithm Example: Results

Situation:– Tasks P1, P2, P3, P4

Arrive at time t = 0 Priority: P1 highest, P4 lowest Time to process: 10, 2, 5, 3

– Results turnaround response time Highest Priority First: 14.75 9.75 Shortest Job First: 9.25 4.25 Timesharing with Quantum = 2: 12.75 3.0 Timesharing with Quantum 0: 13.5 0

Scheduling Examples UNIX

– preemption– 32 priority levels (round robin)– each second the priorities are recomputed (CPU usage,

nice level, last run)

BSD similar– every 4th tick priorities are recomputed (usage

estimation)

Windows NT– “real time” priorities: fixed, may run forever– variable: dynamic priorities, preemption– idle: last choice (swap manager)

Scheduling Examples: Quantum & Priorities

Win2K:– quantum = 20ms (professional) 120ms (user),

configurable– depending on type (I/O bound)

BSD:– quantum = 100ms– priority = f(load,nice,timelast)

Linux:– quantum = quantum / 2 + priority– f(quantum, nice)

Scheduling Problems Starvation

A task is never scheduled (although ready) “fairness”

DeadlockNo task is ready (nor it will ever become ready) detection+recovery or avoidance

Coffman conditions for a deadlock (1971): Mutual exclusion Hold and wait No resource preemption Circular wait (cycle)

A holds R

A wants S

B holds S

B wants RT Thread

R Resource

Deadlock Conditions

Deadlock Remedies

Coarser lock granularity: use a single lock for all resources (e.g., Linux 2.0-2.4 “Big

Kernel Lock”)

Locking order: resources are ordered resource locking according to the resource order (ticketing)

Two-phase-locking: try to acquire all the resources if successful, lock them; otherwise free them and try again

Deadlock Detection, Prevention & Recovery

Deadlock detection: the system keeps a graph of locks and tries to detect cycles.– time consuming– the graph has to be kept consistent with the actual state

Deadlock prevention (avoidance): remove one of the four Coffman conditions cycles

Recovery:– kill processes and reclaim the resources– rollback: requires to save the states of the processes

regularly

+S +T -S -T+T +R -T -R

+R +S -R -S

Simple Deadlock Scenario Example

– Resources R, S, T– Tasks A, B, C require { R, S }, { S, T }, { T, R } respectively

Case 1: Sequential execution, no deadlock

Simple Deadlock Scenario Case 2: Interleaving, deadlock

graphicalrepresentation

is this a case of deadlock?

Complex Deadlock Scenario Case with 6 resources and 7 tasks

Blocks

Modules

Configuration

Memory

Interrupts

ThreadsTraps

TimersProcessors

Module Lock

Each Kernel Modulehas a lock to protectits data

When multiple locks areneeded, acquire themaccording to the module hierarchy

Deadlock Avoidance Strategy in Bluebottle

Priority Inversion A high-priority task can be blocked by a lower

priority one. Example:

running

waiting

Medium

Priority Inversion Big problem for RTOS Solutions

– priority inheritancelow-priority task holding resource inherits priority of high-priority task wanting the resource

– priority ceilings each resource has a priority corresponding to the highest priority

of the users +1 the priority of the resource is transferred to the locking process can be used instead of semaphores

Example: Mars Pathfinder (1996–1998) VxWorks real-time system: preemptive, priorities Communication bus: shared resource (mutexes) Low priority task (short): meteorological data

gathering Medium priority task (long): communication High priority: bus manager

Detection: watchdog on bus activity system reset Fix: activate priority inheritance via an uploaded on-

the-fly patch (no memory protection).

Locking on Multiprocessor Machines Real parallelism! Cannot “disable interrupts” like on single processor

machines (could stop every task, but not efficient) Software solutions

– Peterson, Dekker, ...

Hardware support– bus locking– atomic instructions

(Test And Set, Compare And Swap)

Locking on multiprocessor machines Test And Set

TAS s:

IF s = 0 THEN

s := 1

CC := TRUE

Compare and Swap (Intel)CAS R1, R2, A:

R1: expected value

R2: new value

A: address

IF R1 = M[A] THEN

M[A] := R2; CC := TRUE

R1 := M[A]; CC := FALSE

These instructions are atomic even on multiprocessors!The usually do so by locking the data bus

Counter s: available resources Binary Semaphores with TAS

Try TAS sJMP TryCS

Spinning(busy wait)

TAS sJMP QueuingCS

Blocking

Example: Semaphores on SMP

Counter s: available resources Generic Semaphores with CAS

P(s)Enter CS

Load R1sTryP MOVE R1R2

DEC R2CAS R1, R2, sBNE TryPCMP R2, 0BN Queuing[CS]

[CS]Load R1s

TryV MOVE R1R2INC R2CAS R1, R2, sBNE TryVCMP R2, 0BNP Dequeuing

Exit CSV(s)

Example: Semaphores on SMP

P(S): { S := S - 1}IF S < 0 THEN

jump queuingEND

V(S): { S := S + 1}IF S <= 0 THEN

jump dequeuingEND

PROCEDURE AcquireSpinTimeout(VAR locked: BOOLEAN);CODE {SYSTEM.i386}MOV EBX, locked[EBP] ; EBX := ADR(locked)MOV AL, 1 ; AL := 1CLI ; switch interrupts off before

; acquiring lock

test:XCHG [EBX], AL ; set and read the lock

; atomically. ; LOCK prefix implicit.

CMP AL, 1 ; was locked?JE test ; retry

END AcquireSpinTimeout;simplified

version

Spin-Locks: the Bluebottle/i386 way

Z = OBJECTVAR myT: T; I: INTEGER;

PROCEDURE & NEW (t: T);BEGIN myT := tEND NEW;

PROCEDURE P (u: U; VAR v: V);BEGIN { EXCLUSIVE } i := 1END P;

BEGIN { ACTIVE } BEGIN { EXCLUSIVE }

AWAIT (i > 0); ENDEND Z;

Condition

Object Activity

Method

Initializer

Mutual Exclusion

Active Objects in Active Oberon

Ready Queue

Running

AwaitingAssertion

AwaitingObject

Active Oberon Runtime Structures

Running

AwaitingAssertion

AwaitingObject

END Run next ready

Preempt Set to ready; Run next ready

NEW Create object; Create process; Set to ready

Active Oberon Implementation

Enter Monitor IF monitor lock set THEN Put me in monitor obj wait list; Run next ready ELSE set monitor lock END

Exit Monitor Find first asserted x in wait list; IF x found THEN set x to ready ELSE Find first x in obj wait list; IF x found THEN set x to ready ELSE clear monitor lock END END Run next ready

Running

AwaitingAssertion

AwaitingObject

Running

AwaitingAssertion

AwaitingObject

6AWAIT Put me in monitor assn wait list; Call Exit monitor

pq < p

end of quantum

Case Study: Windows CE 3.0 Real-time constraints

– Reaction time on events– Execution time

Threads with priorities and time quanta– Priorities: 0 (high), …, 255 (low)– Time quanta in ms

Default 100 ms 0 no quantum

Single processor

EventEvent IRQ

NK.EXE

Kernel Modus

User Modus

Case Study: Windows CE 3.0 Interrupt Handling

– ISR (Interrupt Service Routine) 1st level handling Kernel mode, uses kernel stack Installed at boot-time Creates event on-demand Preempted by ISR with higher priority

– IST (Interrupt Service Thread) 2nd level handling User mode Awaits events

Case Study: Windows CE 3.0 Synchronization on common resources:

– Critical sections: enter, leave operations– Semaphores and mutexes (binary semaphores)

Synchronization is performed with system/library calls (they are not part of a language).

Priority inversion avoidance– priority inheritance (thread inherits priority of task wanting

the resource)

Case Study: Java Activities are mapped to threads (no processes) Synchronization in the language

– locks– signals

Threads provided by the library Scheduling depends on the JVM

Case Study: Java

public class MyThread() extends Thread {

public void run() { System.out.println("Running"); }

public static void main(String [] arguments) { MyThread t = (new MyStread()).start(); }

Case Study: Java

public class MyThread() implements Runnable {

public void run() { System.out.println("Running"); }

public static void main(String [] arguments) { Thread t = (new Thread(this)).start(); }

Case Study: Java Protection with monitor-like objects

– with method granularitypublic synchronized void someMethod()

– with statement granularitysynchronized(anObject) { ... }

Synchronization with signals– wait() (with optional time-out)– notify() / notifyAll() (“send and continue” pattern)

Case Study: Java

private Object o;

public synchronized consume() { while (o == null) { try { wait(); } catch (InterruptedException e) {} } use(o); o = null; notifyAll();}public synchronized void produce(Object p) { while (o != null) { try { wait(); } catch (InterruptedException e) {} } o = p; notifyAll();}

Case Study: POSIX Threads Standard interface for threads in C Mostly UNIX, possible on Windows Provided by a library (libpthread) and not part of the

language. IEEE POSIX 1003.1c standard (1995) Various implementations (both user and kernel

level)

Case Study: POSIX Threads

#include <pthread.h>

pthread_mutex_t m;

void *run(){ pthread_mutex_lock(&m); // critical section pthread_mutex_unlock(&m); pthread_exit(NULL);}

int main (int argc, char *argv[]){ pthread_t t; pthread_create(&t, NULL, run,NULL); pthread_exit(NULL);}

File Systems

File Systems - Overview Hardware File abstraction File organization File systems

– Oberon– Unix– FAT

Distributed file systems– NFS– AFS

Special topics– Error recovery– ISAM– B* Trees

Hardware: the ATA Bus ATA / IDE (1986)

– Advanced Technology Attachment

– Integrated Drive Electronics ATA-2 / EIDE ATA-4 / ATAPI

– ATA Packet Interface(SCSI command set)

ATA-5– UDMA 66

ATA-6– UDMA 100– SATA

ATA-7– UDMA 133

bus with 2 devices– master / slave

low-level interface– head / cylinder / sector– support for LBA

(logical block addressing)

PIO mode– read byte by byte through

hardware port

DMA mode– use DMA transfer

Hardware: the SCSI Bus SCSI: Small Computer

Systems Interface SCSI-2

– Fast SCSI– Wide SCSI

SCSI-3

Bus with 8 devices– wide: 16 / 32 devices– bus arbitration– disconnected mode

Device kinds– direct access– CD-ROM– ...

Block-oriented access– read-block, write-block

Transfer mode selection– asynchronous (hand-shake)– synchronous (period / offset)

)rotationaxis

track (cylinder)sector

Hardware: Hard Disk Organization

– cylinder (c)– head (h)– sector (s)

Addressing– sector (c, h, s)– block (LBA)

Hardware: Example

Current disk example: ATA-100 250GB 512 bytes per sector (488·106 sectors) 8MB cache 8.9ms average seek time 7200 rpm

cylinder

Hardware: Hard Disk Improvements Interleaving

optimize sequential sector access

Read-ahead Caching Sector defect management

Hardware: Disk Scheduling Disk controllers have a queue of pending requests:

– type: read or write– block number: translated into the (h,c,s)-tuple– memory address (where to copy from and to)– amount to be transferred (byte or block count)

Hardware: Disk Scheduling

First-come, first-served (FCFS)

Shortest-seek-time-first (SSTF)

SCAN (elevator) &C-SCAN

LOOK &C-LOOK

Performance: minimize head movements, maximize throughput

Scheduling is now in the hardware

Hardware: Disk Scheduling Example (head position, track number):

queue = 31, 72, 4, 18, 147, 193, 199, 153, 114, 72

Hardware: Disk Scheduling

Abstractions

Block: array of sectors some systems call

them “clusters” user configured reduces address space increases access

speed causes internal

fragmentation

Disk: array of sectors

File: stream of bytes sequential access random access stored on disk

– mapping byte to block– block allocation

management

ReadSector, WriteSector

Volume

ReadBlock, WriteBlockAllocateBlock, FreeBlock

File System

OpenFile, WriteFile, ReadFile, SeekFile, CloseFile

Abstractions Implementations

ATA driver

SCSI driver

Oberon

ISO 9660

Abstraction Layers

File Organization How can we map groups of blocks into files? How do we manage free space? How can I jump to a certain location?

Operation: read n bytes at position p.

File Organization: Contiguous Allocation

File is a group of contiguous blocks Simple management Fast transfers IBM MVS (mainframe)

start length

File Organization: Contiguous Allocation

external fragmentation allocation

– how much space does a file need?– first fit, best fit, …?

file growth (error? move? extensions?) preallocation: internal fragmentation

start length

File Organization: Linked Allocation File is a linked list of blocks

– no external fragmentation– no growth problems

Problems– sequential files only (positioning requires traversal)– space for pointers (1TB, 5B addr., 1% with 512B blocks)– reliability (lost pointers)

File Organization: Linked Allocation Clusters: series of contiguous blocks

– faster (less jumps)– less space wasted for pointers– internal fragmentation

File Organization: Linked Allocation Pointer tables

– the list of pointers is stored in a separate table– can be cached– usually is stored twice (reliability)– FAT (MS-DOS, OS/2, Windows, solid-state memory)

File Organization: Indexed Allocation Index with block addresses Fast access for random-access files No external fragmentation Problems

– high management overhead– limited file size (depending on the index structure)– pointer overhead

File Organization: Indexed Allocation Variation:

– linked list of indexes

Advantage:– no file size limitation

Disadvantage:– Index lookup requires sequential traversal of index list

File Organization: Indexed Allocation multi-level indexes

(index of indexes) UNIX

Advantage:– fast index lookup

Disadvantage:– limited file size

File Organization: Indexed Allocation

Example: blocks 2KB address 4B

First level index blocks:512 entries · 2KB = 1MB

Second level index block:512 entries · 2KB = 0.5GB

Free Space Management Bitmap (e.g., HFS)

– bit vector to mark free blocks– simple– needs caching

Linked lists– list of free blocks (similar to linked allocation)

Grouping– free blocks contain n address of free blocks (similar to

multilevel indexing)

Counting– list of 2-tuples of series of free blocks (start, length)

Case Study: Oberon File System Disk module: controller driver

– block management FileDir module:

– maps files to locations– implemented with B-trees– garbage collection (files)

the directory is the root set anonymous (nonregistered) files are collected

Files module:– allows user operations (read, create, write,

…)– access is performed through riders

FileDir

Characteristics Block size = 1KB File organization

– multilevel index: 64 direct 12 1st level indirect

– 672 data bytes in file header

Block allocation– allocation table created at boot-time (partition GC)– no collection at run-time (partition fills up!)

designed to optimize

small files

Case Study: Oberon File System

(672B)(672B)

12 index blocks with 256data blocks each

64 blocks

Case Study: Oberon File System Block = 1KB

Free block management: bitmap

Garbage collection at startup

11111111111111111111111111111111

11010010011110111101110100011100

11010010011110110001110100011100

11010010011110110000110100011100

startup / GC

allocate 16,17

allocate 19

0 8 16 24

File Handle

Buffer

“Hint”

Internals “Rider”: current read

or write position Buffer (cache) for

consistency (each filesees the write operationson it)

Case Study: Oberon RAM Disk

File = POINTER TO Header;Index = POINTER TO Sector;

Rider = RECORDeof: BOOLEAN;file: File;pos: LONGINT;adr: LONGINT;

Header = RECORDmark: LONGINT;name: FileDir.Name;len, time, date: LONGINText: ARRAY 12 OF Index;sec: ARRAY 64 OF SectorTable;

exttable

primarysectortable

header

points tosectors 0 - 63

indexsector 0

points tosectors64 - 319

indexsector 1

points tosectors320 - 575

PROCEDURE Read(VAR r: Rider; VAR x: SYSTEM.BYTE);VAR m: INTEGER;

BEGINIF r.pos < r.file.len THEN SYSTEM.GET(r.adr, x); INC(r.adr); INC(r.pos);IF r.adr MOD SS = 0 THEN (*end of sector *)m := SHORT(r.pos DIV SS);IF m < STS THEN

r.adr := r.file.sec[m]ELSE

r.adr := r.file.ext[(m-STS) DIV XS].x[(m-STS) MOD XS]END

ENDELSE x := 0X; r.eof := TRUEEND

END Read;

SS = Sector SizeSTS = Sector Table SizeXS = Index Size

PROCEDURE Write(VAR r: Rider; x: SYSTEM.BYTE);VAR k, m, n: INTEGER; ix: LONGINT;

BEGINIF r.pos < r.file.len THENm := SHORT(r.pos DIV SS); INC(r.pos);IF m < STS THEN

r.adr := r.file.sec[m]ELSE

r.adr := r.file.ext[(m-STS) DIV XS].x[(m-STS) MOD XS]END

ELSE....

END;SYSTEM.PUT(r.adr, x); INC(r.adr);

END Write;

overwrite

Case Study: Oberon RAM DiskIF r.pos < r.file.len THEN ....ELSE IF r.adr MOD SS = 0 THEN m := SHORT(r.pos DIV SS); IF m < STS THEN Kernel.AllocSector(0, r.adr); r.file.sec[m] := r.adr ELSE n := (m-STS) DIV XS; k := (m-STS) MOD XS; IF k = 0 THEN Kernel.AllocSector(0, ix); r.file.ext[n] := SYSTEM.VAL(Index, ix) END; Kernel.AllocSector(0, r.adr); r.file.ext[n].x[k] := r.adr END; INC(r.pos); r.file.len := r.pos END; SYSTEM.PUT(r.adr, x); INC(r.adr);

expand

Case Study: UNIX, inodes

Inode: file owner file type

– regular / directory / special

access permissions access time reference count (links) table of contents file size

Inode table of contents 10 (12) direct blocks 1 indirect block 1 double indirect block 1 triple indirect block

File system: files and directories (files with a special content) A file is represented by an inode

ddi3i3 i2i2

101112

i3 i2 i1 d

typeaccess

Case Study: UNIX, directories Directories are normal files with a special content. The data part contains a list with

– inode– name

Every directory has two special entries– . the directory itself– .. the parent directory

type: dirblocks: 132owner: rootref count: 1

inode 2

/2 .2 ..4 bin3 root

block 132

inode 3

/root/3 .2 ..5 .tcshrc6 mbox

block 406

type: fileblocks: 42, 103owner: rootref count: 1

inode 6

datablock 42

block 103

inode # name

inodes

disk block

Case Study: UNIX, soft and hard links Hard links:

– two directories entries with the same inode number– each file has a reference counter

42 file42 hardlink

Soft links– the directory entry points to a special file with the path of

the linked file

42 file43 softlink

(inode 43 points to a special file with the path of file)

Case Study: UNIX, hard links

inode 2

/2 .2 ..4 bin3 root

block 132

inode 3

/root/3 .2 ..5 mails5 mbox

block 406

type: fileblocks: 42, 103owner: rootref count: 2

inode 5

datablock 42

block 103

inodes

disk block

Case Study: UNIX, soft links

inode 2

/2 .2 ..4 bin3 root

block 132

inode 3

/root/3 .2 ..5 mbox6 mails

block 406

type: fileblocks: 42owner: rootref count: 1

inode 5datablock 42

type: fileblocks: 43owner: rootref count: 1

inode 6/root/mboxblock 43

Case Study: UNIX, Volume Layout

A volume (partition) contains boot block

– bootstrap code

super block– size– max file– free space– …

inodes data blocks

bootblock

superblock inode list data blocks

Case Study: UNIX, Functions

Core functions breadread block bwrite write block

iget get inode from disk iput put inode to disk bmapmap (inode, offset) to disk block namei convert path name to inode

Case Study: UNIX, namei

namei (path)

if (absolute path)inode = root;

elseinode = current directory inode;

while (more path to process) {read directory (inode);if match(directory, name component) {inode = directory[name component];iget(inode);

} else {return no inode;

return inode;

FATnn: nn corresponds to the FAT size in bits FAT12, FAT16, FAT32 used by MS-DOS and

Windows for disks and floppies Volume Layout

bootblock

FAT1 FAT2 rootdirectory

Case Study: FAT

Case Study: FAT, Example0

5 FREE

10 EOF

12 EOF

13 FREE

6 9 11 10

File 1:

File 2:

File 3:

disksize

Case Study: FAT, Directory Information about files is kept in the directory

File name (8)

Extension (3)

A D V S H R

Reserved (10)

Time (2)

Date (2)

First block (2)

File size (4)

Case Study: FAT, Max. Partition Size

Block size FAT-12 FAT-16 FAT-32

0.5 KB 2 MB

1 KB 4 MB

2 KB 8 MB 128 MB

4 KB 16 MB 256 MB 1 TB

8 KB 512 MB 2 TB

16 KB 1024 MB 2 TB

32 KB 2048 MB 2 TB

File System Mounting More than one volume mounted in the same

directory tree.

floppy

home corti

afs ethz.ch

Virtual File System Support for several file systems

– disk based– network– special

VFS: unifies the system calls Mirrors the traditional UNIX file system model

Applications

ext3 FAT NFS AFS proc pts

ext3 FAT NFS AFS proc ptsVFS

File System Mounting Each file system type has a method table System calls are indirect function calls through the method

table Common interface (open, write, readdir, lock, …) Each file is associated with a the method table

File System Mounting: Special Files Devices

– disks– memory– USB devices– serial ports– …

Kernel communication (e.g., proc) Uniform interface (open, close, read, write) Uniform protection (user, groups)

File Systems: Protection Restrict: access (who), operations (what),

management– FAT: flags in the directory

e.g., read only execution based on name

– UNIX: restrictions in inodes based on users and groups operations: read, write, execute directories: manage files not so flexible

– VMS: access lists list of users and rights per file

Distributed File Systems

Distributed File Systems (DFS) Clients, servers and storage are dispersed among

machines in a distributed system.

Client Client

ClientClient

Client

Server

ServerServer

Client

Server

Overview

Naming (dynamic): location

transparency: file name does not reveal the file location

location independence: file name does not change when storage is moved

Caching (efficiency) write-through delayed-write write-on-close

Consistency client-initiated: poll

server for changes server-initiated: notify

clients

Naming Simple approaches:

– file is identified by a host, path pair– Ibis (host:path)– SMB (\\host\path)

Transparent– remote directory are mounted in the local file system– not uniform (the mount point is not defined)– NFS (/mnt/home, /home/)– SMB (\\host\path mounted on Z:)

Global name structure– uniform and transparent naming– AFS (/afs/cell/path)

Caching Reduces network and disk load Consistency problems Granularity:

– How much? Big/small chunks of data? Entire files?– Big: +hit ratio, +hit penalty, +consistency problems

Location:– memory: +diskless stations, +speed– disk: +cheaper, +persistent– hybrid

Space consumption on the clients

Caching

Policies: write-through: +reliability, -performance (cache is

effective only for read operations) delayed-write: +write speed, +unnecessary writes

eliminated, -reliability– write when the cache is full (+performance, -long time in

the cache)– regular intervals

write-on-close

Consistency Is my cached copy up-to-date? Client-initiated approach:

– the client performs validity checks– when? open/fixed intervals/every access

Server-initiated approach:– the server keeps track of cached files (parts)– notifies the clients when conflicts are detected– should the server allow conflicts?

Stateless and Stateful Servers

Stateful: the server keeps track of each accessed file session IDs (e.g., identifying an inode on the server) fast

– simple requests– caches– fewer disk accesses– read ahead

volatile– server crash: rebuild structures (recovery protocol)– client crash: orphan detection and elimination

Stateless and Stateful Servers

Stateless: each request is self-contained request: file and position complex requests need for uniform low-level naming scheme (to avoid

name translations) need idempotent operations (same results if

repeated)– absolute byte counts

No locking possible

File Replication A file can be present on failure independent

machines Naming scheme manages the mapping

– same high-level name– different low-level names

Transparency Consistency

Distributed File-Systems (mainstream) NFS: Network File System (Sun) AFS: Andrew File System (CMU) SMB: Server Message Block (Microsoft) NCFS: Network Computer FS (Oberon)

Network File System (NFS) UNIX - based (Sun) mount file system from

another machine into local directory

stateless (no open/close)

uses UDP to communicate

based on RPC and XDR (External Data Representation)– every operation is a

remote procedure call

known problems:– no caching– no disconnected mode– efficiency

security: IP based

NFS: Example

server

exports

/home/ client(rw)

mount -t nfs server:/home /home client

NFS No special servers (each machine can act as a

server and as a client) Cascading mounts are allowed

– mount -t nfs server1:/home /home– mount -t nfs server2:/projects/corti /home/corti/projects

Limited scalability (limited number of exports)

NFS: Stateless Protocol Each request contains a unique file identifier and an

absolute offset No concurrency control (locking has to be

performed by the applications) Committed information is assumed to be on disk

(the server cannot cache writes)

Network File System (NFS)

Virtual file system layer

System call layer

Local filesystem

NFS client

RPC / XDR

Virtual file system layer

Local filesystem

NFS server

RPC / XDR

network (UDP)

Big-endian: MSB before LSB• IBM, Motorola, SPARC

Little-endian: LSB before MSB•VAX, Intel

network byte-

ordering

little end first

Remote Procedure Invocation: Overview

Problem– send structured information

from A to B– A and B may have different

memory layouts– byte order problems

– How is 0x1234 (2 bytes) represented in memory?

Marshalling / SerializationMarshalling: packing one or

more data items into a buffer using a standard representation

Presentation layer (OSI)

RPC + XDR (Sun)– RFC 1014, June 1987– RFC 1057, June 1988

IIOP / CORBA (OMG)– V2.0, February 1997– V3.0, August 2002

SOAP / XML (W3C)– V1.1, May 2000

XDR Type System [unsigned] integer (32-bit) [unsigned] hyper-integer

(64-bit) enumeration (unsigned int) boolean (enum) float / double (IEEE 32/64-

bit) opaque string array (fix + variable size) structure union void

Client

procedure P(a, b, c)•pack parameters•send message toserver

•await response

•unpack response

Server

•unpack parameters• find procedure• invoke•pack response•send response

P(a, b, c)

RPC Protocol Remote procedure call Marshalling of procedure

parameters

Message format Authentication Naming

Client Server

lookup lookup

read read

write write

RPC - protocol

NFS Efficiency Stateless protocols are inherently slow

– e.g., directory lookup

Caching:– file blocks (data)– file attributes (inodes)

– read-ahead– delayed write

– tradeoff between speed and consistency

It is possible that two machines see different data

NFS: Security Exports based on IP addresses

– low security– low granularity

Data is not encrypted Permissions based on user and group ID

– uniform naming needed (e.g., NIS)

Andrew File System (AFS) 1983 CMU (later IBM, now open source) Scalable (>5000 workstations):

– network divided in clusters (cells)

Client/user mobility (files are accessible from everywhere)

Security: encrypted communication (Kerberos) Protection: control access lists Heterogeneity: clear interface to the server

Andrew File System (AFS) server provides a cell world-wide addressing

scheme (name cell) client caches a whole

file server-synchronization

on file open and close

AFS is efficient low network overhead stateful: consistency is

implemented with callbacks

callback = client is in synch with server

on store, server changes the callbacks

AFS: Logical View

dir dir

binusr

Shared Space

PrivateSpace

Volume

Mount Point

AFS: Physical View

ethz.ch

epfl.ch

cmu.edu

clientsever

network

Client Server

open open

RPC - protocol

AFS: Consistency Interaction only when opening and closing files. Writes are not visible on other machines before a

close. Clients assume that cached files are up-to-date. Servers keep track of caching by the clients

(callbacks)– clients are notified in case of changes

AFS: Kerberos Kerberos (Cerberos: three-headed dog guarding the

Hades)– authentication– accounting– audit

Needham-Schroeder shared key protocol Distributed AFS: communication is encrypted

AFS: Protection

Access lists:%> fs listacl thesis

Access list for thesis is

Normal rights:

system:anyuser l

trg rlidwk

corti rlidwka It’s possible to allow (or deny) access to users or

customized groups Restriction on: read, write, lookup, insert,

administer, lock and delete. Supports UNIX control bits.

The Eight Fallacies of Distributed Computing (Peter Deutsch)

Network Fallacies

The network is reliable Latency is zero Bandwidth is infinite The network is secure

The network topology doesn’t change

There is one administrator Transport cost is zero The network is

homogeneous

General Principles (Satyanarayan)

From DFSs we learned the following lessons: we should try to move computations to the clients use caching whenever possible special files (e.g., temporary) can be specially

treated. make scalable systems. trust the fewest possible entities batch work if possible

Kernel Structure

Introduction Kernel performs “dangerous” operations

– page table mapping– scheduling

Kernel must be protected against malign user code– access to other processes’ data– increasing own processes’ priority

Kernel must have more rights than user code Solution:

– distinguish between kernel mode and user mode– access kernel through system calls– the system calls define the interface to the kernel

application application applicationsystem calls

Kernel Protection

application application application

driversmemorymanager

filesystems

Kernel Protection

Means: hardware support

– privileged instructions– supervisor mode

separate address spaces– user process has no access to kernel structures

access memory / functions through symbolic names– user has no access to hardware

Kernel Protection Privileged instructions in user mode generate a trap Mode switch:

– interrupts– gated calls (user generated sw interrupt calls)

Parameters:– stack– registers

Examples:– Intel x86: 4 protection levels (code/segment attribute),

interrupt– PowerPC: 2 levels (CPU attribute), special instruction

Linux System Calls (Intel) System calls are wrapped in libraries (e.g., libc) The library function

– writes the parameters in registers (5)– writes the parameters on the stack (>5)– writes the system call number in EAX– calls int 0x80

The kernel– jumps to the corresponding function in sys_call_table

Linux System CallsExamples: pid_t fork(void): creates a child process ssize_t write(int fd, const void *buf, size_t count): writes count bytes from buf to fd

int kill(pid_t pid, int sig): send signal to a process

int gettimeofday(struct timeval *tv, struct timezone *tz): gets the current time

int open(const char *pathname, int flags): opens a file

int ioctl(int d, int request, ...): manipulates special devices

Windows System Calls Layered system: system

call must be performed by a wrapper (NTDLL.DLL).

The system call position in the KiSystemServiceTable is not known (depends on the build)

call WriteFile()

KiSystemServiceTable

NtWriteFile()

application

KERNEL32.DLL

…int 0x2e

NTDLL.DLL

Kernel Design: API vs. System Calls

Linux system-calls are clearly

specified (POSIX standard) system-calls do not change about 100 calls

Windows system-calls are hidden only Win32 API is published Win32 is standard “thousands” of API calls,

still growing some API calls are handled

in user space More than one API:

– POSIX– OS/2

Protection and SMP What happens when two process (on two CPUs)

enter in kernel mode?– Big kernel lock: not allowed (OpenBSD, NetBSD)– Fine grained locks in the kernel (FreeBSD 5, Linux 2.6)

CPU 1 CPU 2

proc1:

int 0x80

proc1:

int 0x80

Kernel Structure monolithic kernel

– big mess, no structure, one big block, fast– MS-DOS (no protection), original UNIX– micro-kernel (AIX, OS X)

layered system– layern uses functions from layern-1

– OS/2 (some degree of layering)

virtual machine– define artificial environment for programs

client-server – tiny communication microkernel to access various

services

Monolithic Kernels

terminal controllersdevice drivers

memory controllers

schedulersignal handling

file systemswapping

virtual memory

user-levelapplications

terminal controllersdevice drivers

memory controllers

schedulersignal handling

file systemswapping

virtual memory

user-levelapplications

Monolithic Micro-kernel

Layered Systems THE operating system A layer uses only functions from

below What goes where? Less efficient

user programs

buffering I/O

console drivers

memory management

CPU scheduling

hardware

Virtual Machines VM operating system (IBM) slow and difficult to implement complete protection no sharing of resources useful for development and

research compatibility

hardware

virtual machine

procs procs procs

Design: Kernel or User Space?

Big monolithic kernel: fast (less switches) less protection

Examples: HTTP server in the Linux

kernel. graphic routines in

Windows

Modular and micro-kernels: structured more separation move code to user space less efficient more secure

Example: user level drivers

Virtual Machines Machine specification in

software– instruction set– memory layout– virtual devices– ....

JVM (Java Virtual Machine) .NET / Mono VMWare

– specified machine is a whole PC

– allows multiple PC environments on same machine

IBM VM/370

Case Study: JVM

Reality is somewhat fuzzy!

Is a Pentium-II a machine?

Hardware and software are

logically equivalent

(A. Tanenbaum)

RISCCore

instructions

decoderOp1

Virtual Machines

What is a machine? does something (...useful) programmable concrete (hardware)

What is a virtual machine? a machine that is not

concrete a software emulation of a

physical computing environment

Virtual Machine, Intermediate Language Pascal P-Code (1975)

– stack-based processor– strong type machine language– compiler: one front end, many back ends– UCSD Apple][ implementation, PDP 11, Z80

Modula M-Code (1980)– high code density– Lilith as microprogrammed virtual processor

JVM – Java Virtual Machine (1995)– Write Once – Run Everywhere– interpreters, JIT compilers, Hot Spot Compiler

Microsoft .NET (2000)– language interoperability

JVM Case Study compiler (Java to bytecode) interpreter, ahead-of-time

compiler, JIT dynamic loading and linking exception Handling memory management,

garbage collection

OO model with single inheritance and interfaces

system classes to provide OS-like implementation

– compiler– class loader– runtime– system

JVM: Type System Primitive types

– byte– short– int– long– float– double– char

– reference– boolean mapped to int

Object types– classes– interfaces– arrays

Single class inheritance Multiple interface

implementation Arrays

– anonymous types– subclasses of

java.lang.Object

JVM: Java Byte-Code

Memory access tload / tstore ttload / ttstore tconst getfield / putfield getstatic / putstatic

Operations tadd / tsub / tmul / tdiv tshifts

Conversions f2i / i2f / i2l / .... dup / dup2 / dup_x1 / ...

Control ifeq / ifne / iflt / .... if_icmpeq / if_acmpeq invokestatic invokevirtual invokeinterface athrow treturn

Allocation new / newarray

Casting checkcast / instanceof

JVM: Java Byte-Code Example

bipush

Operation Push byte

Format

Forms bipush = 16 (0x10)

Operand Stack ... => ..., value

Description The immediate byte is sign-extended to an int value. That value is pushed onto the operand stack.

bipush

JVM: Machine Organization

Virtual Processor stack machine no registers typed instructions no memory addresses, only

symbolic names

Runtime Data Areas pc register stack

– locals– parameters– return values

heap method area

– code

runtime constant pool native method stack

iload 5iload 6iaddistore 4

iaddv5+v6

locals

istore 4

iload 5

iload 6

operand stack

JVM: Execution Example

JVM: Reflection

java.lang.Class– getFields– getMethods– getConstructors

java.lang.reflect.Field– setObject getObject– setInt getInt– setFloatgetFloat– .....

java.lang.reflect.Method– getModifiers– invoke

java.lang.reflectConstructor

Load and manipulate unknown classes at runtime.

JVM: Reflection – Example

import java.lang.reflect.*;

public class ReflectionExample {

public static void main(String args[]) { try { Class c = Class.forName(args[0]); Method m[] = c.getDeclaredMethods(); for (int i = 0; i < m.length; i++) { System.out.println(m[i].toString()); } } catch (Throwable e) { System.err.println(e); } }}

JVM: Java Weaknesses

Transitive closure of java.lang.Object contains 1.1 47 1.2 178 1.3 180 1.4 248 5 (1.5) 280 classpath 0.03 299

class Object {public String toString();....

}class String {

public String toUpperCase(Locale loc);....

} public final class Locale implements Serializable, Cloneable {

static {y = A.f();

static {x = B.f();

JVM: Java Weaknesses

Class static initialization T is a class and an instance of T

is created

T tmp = new T(); T is a class and a static method

of T is invoked

T.staticMethod(); A nonconstant static field of T is

used or assigned(field is not static, not final, and not initialized with compile-time constant)

T.someField = 42;

Problem circular dependencies in static

initialization code

JVM: Java Weaknessesinterface Example {

final static String labels[] = {“A”, “B”, “C”}}

hidden static initializer:labels = new String[3];

labels[0] = “A”; labels[1] = “B”; labels[2] = “C”;

Warning: in Java final means write-once! interfaces may contain code

JVM: Memory Model The JVM specs define a memory model:

– defines the relationship between variables and the underlying memory

– meant to guarantee the same behavior on every JVM

The compiler is allowed to reorder operations unless synchronized or volatile is specified.

JVM: Reordering read and writes to ordinary variables can be

reordered.public class Reordering { int x = 0, y = 0;

public void writer() { x = 1; y = 2; }

public void reader() { int r1 = y; int r2 = x; }}

JVM: Memory Model synchronized: in addition to specify a monitor it

defines a memory barrier:– acquiring the lock implies an invalidation of the caches– releasing the lock implies a write back of the caches

synchronized blocks on the same object are ordered.

order among accesses to volatile variables is guaranteed (but not among volatile and other variables).

JVM: Double Checked Lock

Singleton

public class SomeClass {

private static Resource resource = null;

public Resource synchronized getResource() { if (resource == null) { resource = new Resource(); } return resource; }}

Double checked locking

private static Resource resource = null;

public Resource getResource() { if (resource == null) { synchronized (this) { if (resource == null) { resource = new Resource(); } } } return resource; }}

Thread 1 Thread 2

private Resource resource = null;

public Resource getResource() { if (resource == null) { synchronized { if (resource == null) { resource = new Resource(); } } } return resource; }}

private Resource resource = null;

public Resource getResource() { if (resource == null) { synchronized { if (resource == null) { resource = new Resource(); } } } return resource; }}

The object isinstantiated

but not yet initialized!

JVM: Immutable Objects are not Immutable Immutable objects:

– all types are primitives or references to immutable objects– all fieds are final

Example (simplified): java.lang.String– contains

an array of characters the length an offset

– example: s = “abcd”, length = 2, offset = 2, string = “cd”

String s1 = “/usr/tmp”String s2 = s1.substring(4); //should contain “/tmp”

Sequence: s2 is instantiated, the fields are initialized (to 0), the array is copied, the fields are written by the constructor.

What happens if instructions are reordered?

JVM: Reordering Volatile and Nonvolatile Stores

volatile reads and writes are totally ordered among threads

but not among normal variables example

Thread 1 Thread 2

o = new SomeObject;initialized = true;

while (!initialized) {sleep();

}o.field = 42;

volatile boolean initialized = false;SomeObject o = null;

JVM: JSR 133 Java Community Process Java memory model revision

Final means final Volatile fields cannot be reordered

Java JVM: Execution Interpreted (e.g., Sun JVM)

– bytecode instructions are interpreted sequentially– the VM emulates the Java Virtual Machine– slower– quick startup

Just-in-time compilers (e.g., Sun JVM, IBM JikesVM)– bytecode is compiled to native code at load time (or later)– code can be optimized (at compile time or later)– quicker– slow startup

Ahead-of time compilers (e.g., GCJ)– bytecode is compiled to native code offline– quick startup– quick execution– static compilation

JVM: Loader – The Classfile Format

ClassFile {

version

constant pool

super class

interfaces

fields

methods

attributes

Constants: Values

String / Integer / Float / ... References

Field / Method / Class / ...

Attributes: ConstantValue Code Exceptions

JVM: Class File Formatclass HelloWorld {

public static void printHello() {System.out.println("hello, world");

public static void main (String[] args) {HelloWorld myHello = new HelloWorld();myHello.printHello();

JVM: Class File (Constant Pool)1. String hello, world2. Class HelloWorld3. Class java/io/PrintStream4. Class java/lang/Object5. Class java/lang/System6. Methodref HelloWorld.<init>()7. Methodref

java/lang/Object.<init>()8. Fieldref java/io/PrintStream

java/lang/System.out9. Methodref

HelloWorld.printHello()10. Methodref

java/io/PrintStream.println(java/lang/String )

11. NameAndType <init> ()V12. NameAndType out

Ljava/io/PrintStream;13. NameAndType printHello ()V14. NameAndType println

(Ljava/lang/String;)V

15. Unicode ()V16. Unicode (Ljava/lang/String;)V17. Unicode

([Ljava/lang/String;)V18. Unicode <init>19. Unicode Code20. Unicode ConstantValue21. Unicode Exceptions22. Unicode HelloWorld23. Unicode HelloWorld.java24. Unicode LineNumberTable25. Unicode Ljava/io/PrintStream;26. Unicode LocalVariables27. Unicode SourceFile28. Unicode hello, world29. Unicode java/io/PrintStream30. Unicode java/lang/Object31. Unicode java/lang/System32. Unicode main33. Unicode out34. Unicode printHello

JVM: Class File (Code)Methods

0 <init>() 0 ALOAD0 1 INVOKESPECIAL [7] java/lang/Object.<init>() 4 RETURN

1 PUBLIC STATIC main(java/lang/String []) 0 NEW [2] HelloWorld 3 DUP 4 INVOKESPECIAL [6] HelloWorld.<init>() 7 ASTORE1 8 INVOKESTATIC [9] HelloWorld.printHello() 11 RETURN

2 PUBLIC STATIC printHello() 0 GETSTATIC [8] java/io/PrintStream java/lang/System.out 3 LDC1 hello, world 5 INVOKEVIRTUAL [10] java/io/PrintStream.println(java/lang/String ) 8 RETURN

JVM: Compilation – Pattern Expansion Each byte code is translated according to fix

patterns+ easy- limited knowledge

Example (pseudocode) switch (o) {case ICONST<n>: generate(“push n”); PC++; break;case ILOAD<n>: generate(“push off_n[FP]”); PC++; break;case IADD: generate(“pop -> R1”); generate(“pop -> R2”); generate(“add R1, R2 -> R1”); generate(“push R1”); PC++; break;…

JVM: Optimizing Pattern Expansion

Main Idea: use internal virtual stack stack values are consts / fields / locals / array

fields / registers / ... flush stack as late as possible

iload 4iload 5iaddistore 6

local4 local4

local5

MOV EAX, off4[FP] ADD EAX, off5[FP]

iload4 iload5 iadd istore6

MOV off6[FP], EAXemittedcode

virtualstack

JVM: Compiler Comparison

pattern expansionpush off4[FP]

push off5[FP]

pop EAX

add 0[SP], EAX

pop off6[FP]

optimizedmov EAX, off4[FP]

add EAX, off5[FP]

mov off6[FP], EAX

iload_4iload_5iaddistore_6

5 instructions9 memory accesses

3 instructions3 memory accesses

Linking (General) A compiled program contains references to external

code (libraries) After loading the code the system need to link the

code to the library– identify the calls to external code– locate the callees (and load them if necessary)– patch the loaded code

Two options:– the code contains a list of sites for each callee– the calls to external code are jumps to a procedure

linkage table which is then patched (double indirection)

Linking (General)

0 instr

1 instr

2 jump -

3 instr

4 instr

5 jump -

6 instr

7 jump 2

9 instr

10 instr

proc 0 5

proc 1 7

0 instr

1 instr

2 jump 101

3 instr

4 instr

5 jump 100

6 instr

7 jump 101

9 instr

10 instr

100 jump

101 jump

Linking (General)

0 instr

1 instr

2 jump &p1

3 instr

4 instr

5 jump &p0

6 instr

7 jump &p1

9 instr

10 instr

proc 0 5

proc 1 7

0 instr

1 instr

2 jump 101

3 instr

4 instr

5 jump 100

6 instr

7 jump 101

9 instr

10 instr

100 jump &p0

101 jump &p1

JVM: Linking Bytecode interpreter

– references to other objects are made through the JVM (e.g., invokevirtual, getfield, …)

Native code (ahead of time compiler)– static linking– classic native linking

JIT compiler– only some classes are compiled– calls could reference classes that are not yet loaded or

compiled (delayed compilation) code instrumentation

JVM: Methods and Fields Resolution method and fields are accessed through special VM

functions (e.g., invokevirtual, getfield, …) the parameters of the special call defines the target the parameters are indexes in the constant pool the VM checks id the call is legal and if the target is

presentl

class A {

...B.x}

class B {int x;

B.x CheckClass(B);B.x

IF ~B.initialized THEN

Initialize(B)END;

JVM: JIT – Linking and Instrumentation Use code instrumentation to detect first access of static

fields and methods

C header C source

Compiler

ObjectFileObject

FileObjectFile

Object file

Linker

C header

Loader

LoadedCode

Compilation and Linking Overview

Oberonsource

Compiler

ObjectFileObject

FileObjectFile

Object &Symbol

LoaderLinker

LoadedModule

LoadedModuleLoaded

Module

LoaderLinker

JITCompiler

Javasource

ClassFile

Compiler

ClassLoader

ReflectionAPI

ClassClass

Jaos Jaos (Java on Active Object System) is a Java

virtual machine for the Bluebottle system goals:

– implement a JVM for the Bluebottle system– show that the Bluebottle kernel is generic enough to

support more than one system– interoperability between the Active Oberon and Java

languages– interoperability between the Oberon System and the Java

Metadata

LoaderLinker

LoadedModuleLoaded

Module

OberonLoaderLinker

LoadedModule

Oberonsource

Compiler

Object &Symbol

OberonMetadata

Loader

OberonBrowser

JavaReflection

JITCompiler

LoadedClass

Linker

ClassFile

LoaderJava

MetadataLoader

Jaos (Interoperability Framework)

JVM: Verification Compiler generates

“good” code.... .... that could be

changed before reaching the JVM

need for verification

Verification makes the VM simpler (less run-time checks):

– no operand stack overflow– load / stores are valid– VM types are correct– no pointer forging– no violation of access

restrictions– access objects as they are

(type)– local variable initialized before

load– …

JVM: Verification

Pass1 (Loading): class file version check class file format check class file complete

Pass 2 (Linking): final classes are not

subclassed every class has a

superclass (but Object) constant pool references constant pool names

Byte-CodeVerification

Delayed forperformance

reasons

JVM: Verification

Pass 3 (Linking):

For each operation in code

(independent of the path): operation stack size is the

same accessed variable types are

correct method parameters are

appropriate field assignment with

correct types opcode arguments are

appropriate

Pass 4 (RunTime):

First time a type is referenced: load types when referenced check access visibility class initialization

First member access: member exists member type same as

declared current method has right to

access member

JVM: Byte-Code Verification

Verification: branch destination must

exists opcodes must be legal access only existing locals code does not end in the

middle of an instruction

types in byte-code must be respected

execution cannot fall of the end of the code

exception handler begin and end are sound

Addendum: Security

Security internal protection

– memory protection– file system accesses

external protection– accessibility

problems:– program threats

Security: Program Threats Trojan horses: a code segment

that misuses its environment– mail attachments– web downloads (e.g., SEXY.EXE

which formats your hard disk)– programs with the same name as

common utilities– misleading names (e.g.,

README.TXT.EXE) Trap door (in programs or

compilers): an intentional hole in the software

Security: System Threats worms: a standalone program that spawns other

processes (copies of itself) to reduce system performance– example: Morris worm (1988)

exploited holes in rsh, finger and sendmail to gainaccess to other machines

once on the other machine it was able to replicate itself

– used by spammers to spread and distribute spamming applications

viruses: similar to worms but embedded in other programs– they usually infect other programs and

the boot sector

Security: System Threats Denial of service

– perform many requests to steal all the available resources– often distributed (using worms)

Example: SYN flooding attacks– the attacker tries to connect– the victim answers with a synchronize and acknowledge

packet– and waits for acknowledgment

Countermeasures– active filtering– request dropping– cookie based protocols (requests must be authenticated)– stateless protocols

Security: System Threats badly implemented and designed software:

– lpr (setuid) with an option to delete the printed file– mkdir (first create the inode then change the owner)

it was possible to change the inode before the chown …– buffer overflows– password in memory or swap files– insecure protocols (FTP, SMTP)– missing sanity checks (syscalls, command in input, …)– short keys and passwords– proprietary protocols

Bad design: A very recent example Texas Instruments produces RFID tags offering

cryptographic functionalities. used for cars and electronic payments 40 bit keys proprietary protocol Attack from Johns Hopkins University and RSA

Labs– less than 2 hours for 5 keys– less than 3500$

Security: Buffer Overflows Overwrite a function’s return

address

function foo(int p1, int p2) { char array[10]; strcpy(array, someinput);}

p1 & p2

Avoid strcpy and check the length, e.g., strncpy

Security: Monitoring check for suspicious patterns

– login times

audit logs periodic scans for security holes (bad passwords,

set-uid programs, changes to system programs)– system integrity checks (checksums for executable files)

[tripwire]

network services– monitor network activity

Example: Firewalling Many applications use network sockets to

communicate (even on a single machine) Many applications are not protected

Solution: filter all the incoming connections by default and allow only the trusted ones

Security: (some) Design Principles Open systems (programs and protocols) Default is deny access Check for current authority (timeouts, …) Give the least privilege possible Simple protection mechanisms Do not ask to much to the users (or they will avoid

to protect themselves)

Security and Systems: Some Examples

Enhancements to memory management: Intel XD bit, AMD NX bit mark pages according to the content (data or code) an exception is generated if the PC is moved to a

data address prevents some buffer overflow attacks dynamically generated code has to be generated

through special system calls Windows XP SP2, Linux, BSD …

SELinux National Security Agency (USA) patches to the Linux kernel to enforce mandory

access control open source independent from the traditional UNIX roles (users

and groups) configurable policies restricting what a program is

able to do

OpenBSDaudit process (proactive bug search)random gaps in the stackProPolice: gcc puts a random integer on the

stack in a call prologue and checks it when returning

W^X: pages are writable xor executable

OpenBSDrandomized shared library order and

addressesmmap() and malloc() return randomized

addressesguard pages between objectsprivilege separation and revocation

Privilege Separation unprivileged child process to contain and restrict

the effects of programming errors e.g., openssh

listen *22network connection

monitornetwork

processing

request authauth result

key exchange

authentication

fork unprivileged child

monitoruser requestprocessing

request PTYpass PTY user network data

state export

fork user child

1 Kernfach System Software WS04/05 P. Reali M. Corti.

Documents

Transcript of 1 Kernfach System Software WS04/05 P. Reali M. Corti.

Stainless Steel Reali-Slim Thin Section Bearings

Libero: Design Creation / Verification Seminar WS04/05 Andreas Schibilla (ii4900)

Students Seek Some Reali..

Catalog 300 Engineering and selection guide · 2020-04-09 · 2 1-800-514-3066 Section 1 Introduction Reali-Slim Bearings Catalog 300 Kaydon Bearings Reali-Slim bearings are marked

Autonomous Behavior Control Architecture of Entertainment ...rhaschke/lehre/WS04/humanoids/... · Abstract In this paper we describe the autonomous behavior control architecture of

President Carmela Reali s Message - Italian Heritage Center

Only from KAYDON: REALI-SLIM TT Series — the new ...

BRING YO IMAGINAT TO REALI

Reali-Slim Bearings Open Reali-Slim Bearing Selections ... · Size Land Diameters Dynamic Staticb Bore Outside ... ANGULAR CONTACT ... adjusted at installation to desired running

12. VorlesungModern Methods in Drug Discovery WS04/051 Aktuelle Trends Bioinformatik Stoff dieser Vorlesung.

Reali-Slim Bearings Catalog 300 Kaydon Bearings ......41 Section 2 Selection Tables Kaydon Bearings Reali-Slim Bearings Catalog 300 1-800-514-3066 C. Adhesion Endurakote plating will

Astrophysics I - ETH Zürich - Homepage | ETH Zürich Course Experimental Kernfach 3rd year course: Introduction to Astrophysics Pre-requisites: 1st-2nd year Physics, no prior knowledge

Alessandro Reali - Reluis · Reali, 2008, and references therein): many devices, in particular for biomedical applications, such as, for instance, stents, spinal spacers, and micro-actuators,

Stainless Steel Reali-Slim Thin Section Bearings · Like any Reali-Slim bearing , our stainless steel models have a cross-section that stays constant when the bore size changes, minimizing

Esempi applicatvi reali Michele Pandolf · 2016-07-06 · Michele Pandolf – Esempi applicatvi reali Como, 9 giugno 2016 QUALCHE DETTAGLIO L’edificio, di tipo residenziale, si

Analiza evoluţiei PIB în termeni reali · 76 Romanian Statistical Review - Supplement nr. 3 / 2017 Analiza evoluţiei PIB în termeni reali Prof. univ. dr. Constantin Anghelache

MATHEMATISCHES INSTITUT UNIVERSITÄT …tschinke/WS04/pdf/book.pdfpretation for zeros of L -functions. Here we specialise this construction to the Riemann -function. We construct an

Search Marketing Connect Matteo Zambon 2015 - Google Tag Manager in pratica: Casi reali di utilizzo

President Carmela Reali s Message - Italian Heritage Centeritalianheritagecenter.com/wp-content/uploads/2018/... · Life were Marianne Reali, Quirino Lucarelli, Marie Pardi left to

PUTNAM’S MORAL REALI