Object migration

1. Object migration

2. Distributed object-oriented systems • distributed extensions • Placement of objects on computer nodes • remote calls of objects (location-independent) • migration of objects • system-wide identity • arbitrary granularity remote call object object computer node

3. Distribution of objects logical node A logical node B Thread T1 object O1 object O3 object O2 object O4 internal objects object O5 Thread T2 Object O6 logical node C • Distributed extension of control flows of distribution

4. Distribution of objects • main properties: • remote referencing and localization of objects • distribution- independent method calls • object mobility • advantages • high degree of distribution transparency • facilitated development process • direct remote object access • flexible units of distribution • natural modeling of distributed applications

5. Remote object communication • Phases: • Object localization (from qualifier / name) • Call process (similar to RPC); e.g. with Java Remote Method Invocation (RMI) • Base: proxy concept • Special pointer type • Automatic localization test • Remote reference implementation O1 O2 O2 Proxy for Object O2 Hash-table computer 1 computer 2

6. Localization of fixed objects • proxy contains fixed computer address for object • Implementation through RPC, „binding handles“ possible • example: • public class Proxy { • private Uuid objectId; //qualifier for referenced objects • private RPCBindingHandle bindingHandle; //RPC binding Handle for target computer • public Proxy(Uuid objectId, RPCBindingHandle handle) { ... } //constructor • public RPCBindingHandle getBindingHandle() { ... } //selecting of binding handles • public void updateBindingHandle(RPCBindingHandle handle) { ... } //updating binding Handles • public int forwardCall(Object buf) { //forwarding of calls • return RPC(bindingHandle, objectId, buf); //refined within subclasses • } • }

7. Object mobility Object data • Properties and problems • absolute / limited object mobility • Preservation of transparent access • Proxy-installation • Localization Migration Process Segments start node target node

8. Proxy-installation at migration • Object O2 migrates from R1 to R2: • transfer of object data • synchronization • proxy for O2 on R1, target location R2 • proxies for all references coming from O2 • Example before migration computer R1 computer R2 O1 O2 O3 O4 computer R3

9. Proxy-installation at migration • Object O2 migrates from R1 to R2: • transfer of object data • synchronization • proxy for O2 on R1, target location R2 • proxies for all references coming from O2 • Example after migration computer R1 computer R2 O1 O2 installation of proxy for object O2 installation of proxies for objects O3, O4 O3 O4 computer R3

10. Object mobility • Preservation of transparent access: Localization • Forward addressing • Less migration overhead • More flexible • Scalability • Instant address update • Low overhead for future calls • however migration is more costly, low scalability • Access anomalies

11. Object mobility • central name server • Not flexible, single point of failure, overhead • Only useful at special Object- types„toplevel-objects“ • example: • Naming Service for administration of factories / Home Interfaces in Java • address administration through computer that created an object (“object producer”)

12. Comparison of procedures (schematic) Producing computer for O2 O1 computer 1 computer 2 Localization over: forwarding addressing instant proxy update producing computer O2 computer 3

13. Object localization • Principle: forwarding addressing proxy: Object local to node Object-ID • Forwarding Address • node • Object - ID • time stamp Object on remote node Object table of one node

14. Object localization • localization: • Object already local ? • following of forwarding address • perhaps following further forwarding address (reference chain) • Updating of discovered forwarding addresses • perhaps broadcast- protocol for object search • 1. General broadcast • 2. specific enquiries with answer duty • 3. messages to special nodes

15. Forwarding addressing: details • usage of reference chains (proxy chains): • Updating of location data at the end of call after return of calladvantage: efficient • Update at all computers of the proxy chainadvantage: call of other computers is more efficient, well integrable with RPC (synchronous) • public RPCBindingHandle locate(RPCBindingHandle nodeToAsk, Uuid objectId) { • RPCBindingHandle location = null; //investigate the location • if (LOCAL(objectId)) return nodeToAsk; //object is local • else { • location = locate(PROXY(objectId).getBindingHandle(), objectId); //follow proxy chain • PROXY(objectId).updateBindingHandle(location); //updating of proxy • return location; //returning discovered location • } • } • //initial call • locate(thisNode, oid);

16. combination with producing computer • idea: producing computer is informed about actual location • advantages: • fault tolerance (combination with forward addressing) • efficiency (alternative to long proxy-chains) • but in general forwarding addressing with updated proxy– chains is more efficient at first • public static final int BIAS = 3; • public RPCBindingHandle locate(RPCBindingHandle nodeToAsk, Uuid objectId, int hops) { • RPCBindingHandle location = null; //investigate location • if (LOCAL(objectId)) return nodeToAsk; //object is local • else { • if (hops < BIAS) location = locate(PROXY(objectId).getBindingHandle(), objectId, hops+1); //follow proxy- chains • if (location == null) //error or threshold exceeded • location = locate(CREATINGNODE(objectId).getBindingHandle(), objectId, 0); //ask producing computer • PROXY(objectId).updateBindingHandle(location); //update proxy • return location; // returning discovered location • } • } • //initial call • locate(thisNode, oid, 0);

17. Example for proxy- update • Assumptions: • object was created at R1 • migration to R2,R3,R4,R5 • call from R2 • migration to R2 • call from R4 R1 R2 R3 R4 R5 R1 R2 R3 R4 R5 R1 R2 R3 R4 R5 R1 R2 R3 R4 R5

18. Parameter transfer by migration Call-by-move: migration to called objectCall-by-visit: additional backward migration parameter-object calling object called objekt call-by-move computer 1 computer 2 parameter-object object called object call-by-visit Receiver rcv = find(„MyPartner“); Message m = new Message(); m.edit(); ControlBlock b = new ControlBlock(m); rcv.sendMail(m,b);

19. Object migration: details • motivation: • simplify physical data transfer • reduce number of remote calls • load distribution • public class Node { ... } • public class DObject { • //..definition of instance variables • public DObject(Node ) { ... } //constructor for creating at one computer • public Node locate() { ... } //localization of object • public int move(Node node) { ... } //request an object migration (absolute) • public int move(Dobject obj) { ... } //request an object migration (relative) • public void fix() { ... } //fixation at the short- term location • public void unfix { ... } //dissolving a fixation • public void refix(Node node) { ... } //migration and new fixation • public void refix(DObject obj) { ... } //migration and fixation once more • }

20. Example for migration operations fixed refix form 3 control block call-by-visit calling object called object(class FormChecker) form 1 move? form 2 computer 1 computer 2 public void checkForms(Form f1, Form f2, Form f3, ControlBlock b) { this.fix(); //fixation of formchecker-object if(b.accessMode(„Form1“) == HEAVY) f1.move(this); if(b.accessMode(„Form2“) == HEAVY) f2.move(this); //migration, if intensive access is expected f1.checkData(b);f2.checkData(b); //operation for form check f3.refix(this); //migration and fixation of form#3 f3.print(b); //printing this.unfix(); //deallocation of formchecker- Object }

21. form 3 form 5 form 1 form 2 form 4 component 1 component 1 component 1 component 1 component 1 component 2 component 2 component 2 component 2 component 2 Composition of migration units principle: groups of objects used jointly will be migrated („attachment“)

22. Realization of object migration Start node Target node „call-by-move“ „call-by-visit“ „move“ conversion of object data and treatment of active calls treatment of attachment-references Transfer to target node installation of object data entry of the objects into the object table Replacement of migrated objects by Forward Addresses Forwarding of later calls to a migrated object continuation of active calls on the objects

23. Realization of object migration • public class MigrationSynch { • private AtomicCounter counter; //activation point • public static Object lock = new Object(); //semaphore to migration synchronization • public void operation() { synchronized(lock) { ... } } • public void migrationRequest() { synchronized(lock) { ... } } • } • Conversion of object data at RPC-Base: • public interface Form { • public Uuid objectId; • public Date creationTime; • String formData; • Form component1; • Form component2; • public void FormMigrate(RPCBindingHandle handle, Form form, int status); • }

24. Treatment of control flow • Structure of control flows : • linked stack- segments, assigned to called objects • return addresses distributed • implementation through forward addresses because of migration • Example (call from object A to B to C) stack-segment for call on object A object A stack-segment for call on object B object B (on computer R1) (on computer R2) stack-segment for call on object C object C (on computer R1)

25. Migration of control flows • absolute mobility: called objects are migration- capable • procedure: • identification of active control flows within an object • encoding and transfer of stack- segments • installation and continuation on target computer • identification of control flows through: • references from object to control flow • optimization through delayed installation of references in the context of dispatching • encoding and transfer • complete control flow-information of context necessary • no direct memory addresses / resource-references • limited to homogeneous systems

26. Migration at heterogenic class structures • problems: • object classes on target computer are not available (e.g. in big systems) • different class implementations (e.g. in interactive systems)

27. Multiple implementations of type/class type: DObject Subtyp type: Form type: ... implementation of the type class: Form1 class: Form2 ... ... • individual data structures • individual implementations of the operations • But: common interface and semantics

28. Dynamic installation of classes Principle: explicit request of the class implementation at non- availability migration form 1 (class is not available) form 1 request of class class: form1 transfer of the class (dynamic installation) class: form1 computer 1 confirmation computer 2 example: Java Class Loader

29. automatic memory administration • Principle: • objects, which are not obtainable through references, are deleted • simplification of the application implementation • Start: • fixed system objects are used as „owner“ • Procedure: • reference counter (incremental procedure, but high message expenditure) • marking procedure (batch- like search for objects to be deleted, but it is difficult realizing it at run-time)

30. Reference counter: example 0 O1 0 O2 1 O3 1 O4 O5 1 O6 O7 O8 1 1 1 O9 O10 O11 O12 1 1 2 3 • process (O3,O4: system objects) • O1 and O2 not available  deleted • O6 gets counter mode “zero”  deleted • O9 deleted • but (O5,O8,O12) not recognized

31. Marking procedure: example O1 O2 O3 O4 O5 O6 O7 O8 O9 O10 O11 O12 phase1: mark all available objects phase2: delete all non-marked objects (access via global object table) All objects to be deleted are recognized

32. A C example: B X references (X,2) references (X,3) references (A) references (C) Memory administration at Java RMI • automatic memory administration for distributed Java- objects; • treatment of computer failures by test messages • base: Reference Counting: • at production of the first reference of a process on a remote object: "referenced“- message to server • at further references increment of a local counter • deleting objects automatically if no more references exist