Object and Native Code Thread Mobility Among Heterogeneous Computers

1. Object and Native Code Thread Mobility Among Heterogeneous Computers Bjarne Steensgaard (Microsoft Research ) Eric Jul(DIKU,Dept of Computer Science) Presented by Veena Basavaraj CS5204 FALL 2004

2. Key Ideas • Implement transparent fine grained object and thread Mobility for Heterogeneous Systems at Nativecode level • Conversion among machine-dependent and machine-independent formats • Concept of Bus Stops and Bridging code • Maintain the intra-node Performance achieved inoriginalHomogeneous systems • Byte code and Interpreter not the only solution for platform heterogeneity • Emerald Language and Runtime System used • No change to existing Language CS5204 FALL 2004

3. Presentation Outline • Background – Emerald language and system. • How is Mobility achieved in Homogeneous systems? • Mobility in Heterogeneous systems –Issues and solution. • Prototype Implementation for Emerald. • Recap and Evaluation CS5204 FALL 2004

4. Background – Emerald System • Emerald is an object based language and system for distributed programming • All entities in Emerald system are object, object carries its own immutable code . • All objects have same semantics as seen by a programmer but different implementations provided by the compiler :Global, local, direct objects. • Objects eitherpassive (only data) or active (optional process) CS5204 FALL 2004

5. Background – Emerald System • Fine grainedmobilityin Homogeneous systems achieved with the Emerald language, compiler and runtime kernel support. • Mobility is migration, Smallest unit of migration is object and not the entire process address space as in traditional systems • Language designed with the goal of mobility in a distributed environment , tight coupling with compiler and runtime CS5204 FALL 2004

6. Example :Object Creation in Emerald A name – network unique OID Representation -Data Operations form the Code Invocation on operations is the only form of communication Activation records created for each operation on an object CS5204 FALL 2004

7. Example :Object with Process Constructs to indicate a process CS5204 FALL 2004

8. What is Object Mobility in Emerald ? • Object is able to physically change location within a set of processor nodes • Data and process stack ( only if object active) moves, no code is transferred • Language Primitive - Move (“move X to Y” co-locates X with Y) CS5204 FALL 2004

9. What is Thread Mobility in Emerald ? • Thread is a light weight process running concurrently with others in a single address space • In absence of Object mobility, Thread Mobility is like RPC • In presence of Object mobility : If an active thread is executing an operation in any of the object that is been moved, thread state ( activation record) as well is moved along with the object. CS5204 FALL 2004

10. An Example Node A Consider an active Object X residing on Node A X Object X is active and thus has a process ( Thread of control) Process can make invocations on operations of X or other local and remote objects Process X Stack Base CS5204 FALL 2004

11. RPC The object X on Node A invokes an operation FUNC () in object Y present on Node B. Node A Node B X Y.FUNC( ) Y This is similar to RPC Activation record of Operation FUNC () on object Y Process X Stack Base Process X Stack Segment 1 Demonstrates Thread mobility CS5204 FALL 2004

12. Thread Mobility with object Mobility Node A Node B Y.FUNC( ) { MOVE OBJECT X FROM NODE A TO NODE C } Y Activation record of Operation FUNC () on object Y RETURN TO NODE C Process X Stack Segment 1 Node C X Demonstrates Thread Mobility with Object mobility Process X Stack Base CS5204 FALL 2004

13. How is Mobility achieved in Homogeneous Systems? • Problem : Finding distributed objects and moving data and stack information, pointer translation. • Solution • Emerald Compiler support for generating • Template information for data and activation record for runtime to perform pointer translation and update distributed data structures while migrating • Code to transfer control from user code to the runtime system to preempt the thread at program points • Emerald Runtime support : • to actually perform Object and thread mobility CS5204 FALL 2004

14. Example Program Global Object Local Object Direct object Code CS5204 FALL 2004

15. Emerald Compiler Support – Homogeneous systems • The Compiler generated data structures and templates for Global Object say X • There exists templates for DATA and ACTIVATION RECORDS Concrete Type X: address Operation Code (GetMyName()) Data Area Tag | G | R Code pointer Tag | G | R Monitor lock monitor 1 Data pointer Data 4 Monitor queue Forwarding address if not resident locally Pointer 2 17 Template for DATA address Object Descriptor address Object Descriptor for simpleobject “Emerald” CS5204 FALL 2004

16. Mobility in Heterogeneous Systems • Problem Architecture Heterogeneity leads to differences in number and type of registers, data formats, stack information, program counter values, instruction set . • Solution • Trivial if Byte code execution. But not acceptable in this implementation. • Non–trivial if data and code are represented in machine dependent format on each architecture CS5204 FALL 2004

17. Mobility in Heterogeneous Systems (2) 3 System Dimensions • Migrating Data • Migrating Non-optimized Thread Code • Migrating optimized codes CS5204 FALL 2004

18. Migrating Data • Issue • Differences in format , Data alignment, floating point representation in various architectures • For performance reasons, machine dependent format for data representation • Solution • Convert data representation to and from an agreed format • For instance : use Network Byte order and host byte order functions CS5204 FALL 2004

19. Migrating Threads for non-optimized case • Issue • Machine dependent native code format used for thread code and data representation • Trivial issue – differences in data representation • Non trivial Issue – Different and missing Program Counter (PC) values for same program points on different architectures . • Some Operations may be atomic in certain architectures and thus have single instruction instead of multiple instructions . • Thus, at what PC to migrate is the major Issue! CS5204 FALL 2004

20. Migrating Threads for non-optimized case • Solution: Bus stops as safe migration points • Enumerate all program counters values that have corresponding program counters in all the types of machine dependent code • Assigned numbers are machine independent specification of program points – Bus stops • A compiler is free to reorder and optimize only between and not across Bus stops. Bus Stop 1 Architecture X 4000 INSTRUCT 1 4008 INSTRUCT 1a . . 4020 INSTRUCT 4 . Architecture Y 4020 INSTRUCT 1 . . . 4032 INSTRUCT 4 4040 INSTRUCT 5 Bus Stop 2 CS5204 FALL 2004

21. Migrating optimized codes • Issue – code motion /reordering optimization • How to address compiler optimizations in the code across bus stops • If a thread in node1 with code1 has to be migrated to a node2 with code 2 ? Non-optimized code Optimized code Program point Bus stop CS5204 FALL 2004

22. Migrating optimized codes(2) • Solution – create bridging code with compiler support to ensure exactly once execution of operations on destination node • Step1:The bridging code from “code1” to “abstract” consists of operations op2 and op3. • Step 2:Bridging from “abstract” to “code2” removes op3 and inserts op4 and op5 in the bridging code. • The PC at switch() in code 1 corresponds to PC at op2 in new bridge code fragment CS5204 FALL 2004

23. Prototype Implementation for Emerald • For 4 different architectures • VAX • Sun -3 • HP9000/300 • Sun Sparc • Extensions to Existing Emerald Compiler and Runtime System • Optimized Implementation of Run time system not the primary goal • No Implementation of bridging code CS5204 FALL 2004

24. Changes to Emerald Compiler for heterogeneous systems • Bus Stop information in the compiled code • Information regarding temporary values at Bus stops in the template information for activation records For Example : Consider an expression var sum = f1( x) + f2( y) ; If thread moved at the point where f2(y) is called, the result of f1(x) stored in temporary value should be moved as well. • No changes to generated code CS5204 FALL 2004

25. Changes to Emerald Runtime for heterogeneous systems • Conversion routines added • Changes to marshalling and unmarshalling code for activation record • A bidirectional mapping of PC to Bus stops maintained by runtime CS5204 FALL 2004

26. Evaluation • Novel approach – first implementation for heterogeneity using bus stops concept • But, tight coupling with language, compiler and runtime • Though not used in migration tools, concept of bus stops still used in debugging tools and for garbage collection • Emerald language totally non-conventional for usage but it defined a basis for understanding today’s distributed object systems like CORBA • Only outlined the bridging code technique, no further implementation • Performance results of the prototype implementation inadequate and assumptions made on results Thank You and Questions ? CS5204 FALL 2004

27. Reference Papers • Andrew Black , Norman Hutchinson , Eric Jul , Henry Levy, Object structure in the Emerald system, Conference proceedings on Object-oriented programming systems, languages and applications, p.78-86, September 29-October 02, 1986, Portland, Oregon, United States • Fine-grained mobility in the Emerald system Eric Jul, Henry Levy, Norman Hutchinson, Andrew Black February 1988  ACM Transactions on Computer Systems (TOCS),  CS5204 FALL 2004