1 / 387

Kernfach System Software WS04/05

Kernfach System Software WS04/05. P. Reali M. Corti. Introduction Admin. 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)

melody
Download Presentation

Kernfach System Software WS04/05

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. KernfachSystem SoftwareWS04/05 P. Reali M. Corti

  2. 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)

  3. 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

  4. 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

  5. IntroductionExam • Sometimes in March 2005 • Written, 3 hours • Allowed help • 2 A4 page summary • calculator • Official Q&A session 2 weeks before the exam

  6. 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

  7. 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

  8. Targets mainframes servers multiprocessors desktops real-time systems embedded systems Different goals and requirements! memory efficiency reaction time abstraction level resources security ... IntroductionOperating system target machines

  9. Example: retrieve a list of names memory time Array Nn N List N(n+4) N/2 Bin. Tree N(n+8) log(N) Hash Table 3Nn 1 N = # names n = name length IntroductionMemory vs. Speed Tradeoff

  10. IntroductionOperating System as resource manager ... in the beginning was the hardware! Most relevant resources: • CPU • Memory • Storage • Network

  11. IntroductionLecture Topics Virtual Machine Process DistributedObject-System Abstraction level Thread Coroutine Object-OrientedRuntime Support Scheduling DistributedFile-System Garbage Collection ConcurrencySupport Memory Management Demand Paging Virtual Memory File System Runtime support CPU Memory Disk Network

  12. 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)

  13. IntroductionBootstrapping (Aos) SMP Timers Active Traps Interrupts Modules Module Hierarchy Storage Memory Locks Level Processor

  14. Overview Runtime Support Virtual Addressing Memory Management Distributed Obj. System Concurrency Concurrency Disc / Filesystem Case Study: JVM IntroductionLecture Topics Oct‘04 Jan‘05 Nov‘04 Feb‘05 Dec‘04

  15. Run-time SupportOverview • Support for programming abstractions • Procedures • calling conventions • parameters • Object-Oriented Model • objects • methods (dynamic dispatching) • Exceptions Handling • ... more ...

  16. b.q c.R Stack Pointer (SP) b.q b.q 1 2 b.Q b.Q b.Q b.Q 3 ProcedureActivationFrame (PAF) a.P a.P a.P a.P 4 1 2 3 4 Run-time SupportApplication Binary Interface (ABI) • Object a, b, c, … with methods P, Q, R, … and internal procedures p, q, r, … • Call Sequence Stack 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.Q Return a.P

  17. Run-time SupportProcedure Activation Frame Save Registers Push Parameters Save PC Branch Save FP FP := SP Allocate Locals Caller Stack Pointer (SP) Call locals FramePointer (FP) Dynamic Link FP‘PC Callee params Return Remove Locals Restore FP Restore PC Remove Parameters Restore Registers CallerFrame Caller

  18. 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

  19. Run-time SupportProcedure Activation Frame (Oberon / x86) Caller Callee push params call P push fp mov fp, sp sub sp, size(locals) push pc pc := P mov sp, fp pop fp ret size(params) ... pop pc add sp,size(params)

  20. 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

  21. 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

  22. 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

  23. 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

  24. ObjB ObjA Obj Obj0 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

  25. Run-Time SupportPolymorphism VAR t: Triangle; s: Square; o: Figure; BEGIN t.Draw(); s.Draw(); o.Draw(); END; Type is statically known! Type is discovered at runtime! WHILE p # NIL DO p.Draw(); p := p.next END;

  26. ObjB ObjA Obj Obj0 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

  27. Run-time SupportObject Oriented Support (High-level Java) Type Test Implementation if (a != null) { Class c = a.getClass(); while ((c != null) && (c != T)) { c = c.getSuperclass(); } return c == T; } else { return false; } .... a IS T ....

  28. 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 Descriptors

  29. 2 ObjA ObjB TD(Obj) 3: NIL Obj 2: NIL TD(ObjA) TD(Obj0) 1: Obj 3: NIL 3: NIL 0: Obj0 2: ObjA 2: NIL 1 0 Obj0 1: Obj 1: NIL 0: Obj0 0: Obj0 mov EAX, obj mov EAX, -4[EAX] cmp T, -4 * T.level - 8[EAX] bne .... obj.type.extension[ T.level ] = T “extension level” Run-Time SupportType Tests and Casts (obj IS T)

  30. Run-time SupportObject Oriented Support (High-level Java) Method Call Implementation .... 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); Use method implementation for the actual class(dynamic type)

  31. Run-Time SupportHandlers / Function Pointers TYPE SomeType = POINTER TO SomeTypeDesc; Handler = PROCEDURE (self: SomeType; param: Par); SomeTypeDesc = RECORD handler: Handler; next: SomeType; END root PROC R • Disadvantages: • memory usage • bad integration (explicit self) • non constant • Advantages: • instance bound • can be changed at run-time handler PROC Q next handler next handler next

  32. A.MethodTable 0: A.M0 1: A.M1 B.MethodTable 0: A.M0 1: A.M1 Idea: have a per-type table of function pointers. Run-Time SupportMethod tables (vtables) TYPE A = OBJECT PROCEDURE M0; PROCEDURE M1; END A; B = OBJECT (A) PROCEDURE M0; PROCEDURE M2; END B; B.M0 overrides A.M0 B.M0 B.M2 is new 2: B.M2 • 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

  33. A.MethodTable Virtual Dispatch 0: A.M0 o.M0; 1: A.M1 B.MethodTable call o.Type.Methods[0] 0: B.M0 0: A.M0 1: A.M1 2: B.M2 mov eax, VALUE(o) mov eax, type[eax] mov eax, off + 4*mno[eax] call eax o Type Fields Run-Time SupportMethod tables TYPE A = OBJECT PROCEDURE M0; PROCEDURE M1; END A; B = OBJECT (A) PROCEDURE M0; PROCEDURE M2; END B;

  34. Run-Time SupportOberon Type Descriptors type desc td size type name • method table • superclass table • pointers in object for GC mth table for method invocation ext table type descriptor is also an object! for type checks type desc for object allocation type desc obj size obj fields ptr offsets for garbage collection

  35. Run-Time SupportInterfaces, itables interface A { void m(); } interface B { void p(); } does x implement A? x has anmethod table (itable) for each implemented interface Object x; A y = (A)x; y.m(); multiple itables: how is the right itable discovered?

  36. 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 available Run-Time SupportInterface support use the usual trick: enumerate interfaces

  37. Call is expensive because requires traversing a list: O(N) complexity Run-Time SupportInterface support (I) Type Descriptor interfaces Intf0 Intf7 method table (vtable) method table (itable) method table (itable) interface i = x.type.interfaces; while ((i != null) && (i != Intf0) { i = i.next; } if (i != null) i.method[mth_nr](); Intf0 y = (Intf0)x; y.M();

  38. Run-Time SupportInterface support (II) Lookup is fast (O(1)), but wastes memory Type Descriptor sparse array! interfaces 0 1 2 3 4 5 6 7 vtable Intf0 y = (Intf0)x; y.M(); itable2 interface i = x.type.interfaces[Intf0]; if (i != null) i.method[mth_nr](); itable7

  39. Run-Time SupportInterface Implementation (III) overlap interface table index Type Descriptor u Type Descriptor t interfaces interfaces 0 1 2 3 4 5 6 7 vtablet 0 1 2 3 4 5 6 7 vtablet itableu,2 itablet,2 itableu,0 itablet,7

  40. Run-Time SupportInterface Implementation (III) overlapped interface table index Type Descriptor Type Descriptor interfaces interfaces vtable vtable itable itable itable itable

  41. Run-Time SupportInterface Implementation (III) overlapped interface tables Type Descriptor Intf0 y = (Intf0)x; y.M(); interfaces vtable itable i = x.type.interfaces[Intf0]; if ((i != null) && (i in x.type)) i.method[mth_nr](); itable itable itable itable

  42. void catchOne() { try { tryItOut(); } catch (TestExc e) { handleExc(e); } } void catchOne() 0 aload_0 1 invokevirtual tryItOut(); 4 return 5 astore_1 6 aload_0 7 aload_1 8 invokevirtual handleExc 11 return ExceptionTable From To Target Type0 4 5 TestExc Run-Time Support Exceptions

  43. 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) } pcstart pcend pchandler1 pchandler2 Global Exception Table exception handler start end pcstart pcend Exp1 pchandler1 pcstart pcend Exp2 pchandler2 Run-Time Support Exception Handling / Zero Overhead try { ..... } catch (Exp1 e) { ..... } catch (Exp2 e) { ..... }

  44. 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 Run-Time Support Exception Handling / Zero Overhead system optimized for normal case

  45. push catchdescriptors on the stack Run-Time Support Exception Handling / Fast Handling 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: add code instrumentation try { ..... } catch (Exp1 e) { ..... } catch (Exp2 e) { ..... } pchandler1 pchandler2 use an exception stack to keep track of the handlers

  46. 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 one state.sp = SP; // containing the handler state.pc = handler; // resume with the handler ResumeExecution(state) } Run-Time Support Exception Handling / Fast Handling pop next exception descriptor from exception stack can resume in a different activation frame

  47. code instrumentation insert exception descriptor at try remove descriptor beforecatch fast exception handling overhead even when no exceptions Run-Time Support Exception Handling / Fast Handling system optimized for exception case

  48. 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

  49. Virtual AddressingPages programs use and run in this address spaces • Memory as array of pages virtual address-space 2 unmappedrange unmapped(invalid) page 7 6 5 5 page 3 pageframe 4 0 3 2 1 1 0 2 real memory: pool of page frames 0 memory address virtual address-space 1 mapping

  50. frame page-no Page Table Virtual AddressingPage mapping • Virtual Address  Real Address Virtual Address Real Address TLB page-no off frame off (PT, VA, RA) (PT, VA, RA) (PT, VA, RA) MMU Page Frame off Translation Lookaside Buffer Associative Cache frame Page Table Ptr Register Real Memory

More Related