Fine-Grained Mobility in the Emerald System
-
Upload
patrick-howell -
Category
Documents
-
view
37 -
download
0
description
Transcript of Fine-Grained Mobility in the Emerald System
![Page 1: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/1.jpg)
Fine-Grained Mobility in the Emerald System
Eric Jul, Henry Levy, Norman Hutchinson, Andrew Black
SOSP 1987 & TOCS 1988
Presentation by: norm
![Page 2: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/2.jpg)
Short summary
• A solution in search of a problem!
• We can send objects anywhere, almost for free, but why would you want to?
![Page 3: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/3.jpg)
Goals
• Experiment with mobility in distributed systems– Objects, not processes– Language, not system support
• Single object model
• Excellent local performance
• Two Ph.D. theses!
![Page 4: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/4.jpg)
Benefits
• Process migration– Load sharing– Communications performance– Availability – Reconfiguration – Specialized hardware
• + object migration– Data movement– Invocation performance– Garbage collection
![Page 5: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/5.jpg)
Objects
• Name
• Representation
• Operations
• Process (optional)
![Page 6: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/6.jpg)
Types
• Abstract (think Java interface)
• Concrete (think Java class)
• Conformity is proved by the system rather than declared by the programmer
• Objects are self-describing– don’t need classes
![Page 7: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/7.jpg)
Mobility
• Locate
• Move
• Fix
• Unfix
• Refix
• Attach
• Call by move / visit
![Page 8: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/8.jpg)
Gore
• Processes and mobility– Stack ripping
• Global, local and direct objects
• Object location – forwarding chains
• OIDs, pointers, templates, and swizzling– Registers
![Page 9: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/9.jpg)
Example
const start <- object start
process
const all <- (locate self).getActiveNodes
for i : Integer <- 0 while i <= all.upperbound by i <- i + 1
const m <- Manager.create[self]
move m to all[i].getTheNode
all[i].getTheNode.getStdout.PutString["Created manager here\n"]
end for
end process
end start
![Page 10: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/10.jpg)
Alternative Example
const start <- object start
process
const all <- (locate self).getActiveNodes
for i : Integer <- 0 while i <= all.upperbound by i <- i + 1
move self to all[i].getTheNode
(locate self).getStdout.PutString["Created manager here\n"]
const m <- Manager.create[self]
end for
end process
end start
![Page 11: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/11.jpg)
Performance
• Local invocation 19.4 μsecC: 13.4 μsec
CE: 16.4 μsec
• Remote invocation 27.9 msec+ 1 parameter 3.1 msec
+ 1 call by move/visit parameter ~5 msec
• Migration 12 msec+ process: 28 msec
![Page 12: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/12.jpg)
Performance (2007)
• Local invocation 0.67 μsecC: 0.02 μsec
• Remote invocation 0.37 msec+ 1 parameter 0.01 msec
• Migration 0.37 msec+ process: 0.11 msec
![Page 13: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/13.jpg)
Discussion
![Page 14: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/14.jpg)
Stack ripping
• During a process move, the entire stack is ripped, the object pulled out and then re-assembled on a different machine. Does this happen for call-on-visit as well?
• If so, is the stack now brought back to the original state by once again ripping at the same locations and re-inserting the object there?
• Is this really a good idea?
![Page 15: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/15.jpg)
Yet another language?
• Which language is the Emerald language based on?
• If it is a new language, will many users want to use it?
• Why not just extend the functionality of a compiler for an existing language?
![Page 16: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/16.jpg)
Scalability
• The most questionable thing is the scalability of Emerald.
• Since the unit of distribution and mobility is the object, and objects as described here are not lightweight, do you think this scheme will be scalable when dealing with a heavy workload?
![Page 17: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/17.jpg)
Scalability (II)
• Some assumptions of Emerald are not true today. For example, in today's data centers, we can have more than 1000s of machines which may have different ISAs.
• Do you think the programming paradigm of Emerald is still suitable for today's cluster/data center?
![Page 18: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/18.jpg)
Fault Tolerance
• Is it the programmer’s responsibility to implement the fault tolerance mechanisms in this system?
• Is there any way that the system can provide that?
![Page 19: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/19.jpg)
Object replication
• Is it possible to have two nodes working on the same object? Say if one of them wanted to do a side-effect free operation (like printing out the values in an array) and the other was wanting to update some internal structures?
![Page 20: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/20.jpg)
Residual dependencies
• Can the residual dependencies be avoid in order to improve performance?
• Otherwise there are still some object migrations which are wasteful.
![Page 21: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/21.jpg)
Object location
• The object location mechanism in Emerald system is based on forwarding addresses.
• Why not just keep a directory of nodes referencing objects?
![Page 22: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/22.jpg)
How much transparency?
• Emerald makes it easy to ignore where your objects are, is this a good idea in a distributed system?
• How does location transparency affect failures?
![Page 23: Fine-Grained Mobility in the Emerald System](https://reader035.fdocuments.us/reader035/viewer/2022062321/5681389b550346895da04cfb/html5/thumbnails/23.jpg)
Historical excuses?
• The authors state ‘historical reasons’ for using network communication routines that are slow. Is this a good reason? How often are things done ‘for historical reasons’?