Physical Assembly Mapper: A Model-driven Optimization Tool for QoS-enabled Component Middleware

1. Institute for Software Integrated Systems Vanderbilt University Nashville, Tennessee Physical Assembly Mapper:A Model-driven Optimization Tool for QoS-enabled Component Middleware RTAS 2008, April 22, 2008 Krishnakumar Balasubramanian, Douglas C. Schmidt {kitty,schmidt}@dre.vanderbilt.edu (presented by Aniruddha Gokhale)

2. Context: Distributed Real-time & Embedded (DRE) Systems • Stringent Quality-of-Service (QoS) demands, e.g., real-time constraints • Simultaneous execution of multiple applications with varying importance • Operate under limited resources • e.g., avionics mission computing • Highly heterogeneous platform, language & tool environments • e.g., shipboard computing • Use COTS middleware technologies • CORBA, RT-Java • Use COTS Component/Service-oriented technologies • CORBA Component Model (CCM), EJB, Web Services

3. … … … Container Container Middleware Bus Research Challenge : System Optimization (1/3) Context • Component middleware allows designing systems that are • Hierarchical, i.e., individual components easily combined to form assemblies • Reusable, i.e., each component can be used in multiple composition contexts • Containers provide execution environment for components with common operating requirements • Components communicate via the middleware bus Optimizations are key to assure DRE system QoS

4. Research Challenge: System Optimization (2/3) Current state of optimizations: • Collocated method invocations • Optimize the (de-)marshaling costs by exploiting locality • Specialization of request path by exploiting protocol properties • Caching, Compression, various encoding schemes • Reducing communication costs • Moving data closer to the consumers by replication • Reflection-based approaches • Choosing appropriate alternate implementations at run-time

5. Research Challenge : System Optimization (3/3) Problem • Systems with large number of components tend to exhibit • Footprint overhead due to auxiliary middleware infrastructure in certain composition contexts • e.g., component factories/ contexts when the components are collocated • Latency overhead due to sub-optimal configuration of middleware • e.g., latency between components placed in different containers Need additional optimizations to component middleware

6. Component System Optimizations: Unresolved Challenges Composition overhead in large-scale systems • Blind adherence to platform semantics • Inefficient middleware glue code generation per component • Examples: • Creation of a factory object & component context per component • Increase in overhead with increase in number of components

7. Solution Approach: Deployment-time Fusion • New class of optimization techniques – deployment-time fusion • Merges multiple elements, e.g., components, QoS policies, into a semantically equivalent element • Differences in fusion techniques • Type of elements fused • Scope of fusion • Rules governing fusion • e.g., Component Fusion • Merges multiple components into a single component subject to fusion constraints

8. Intuition behind Deployment-time Fusion Soln If n = no. of candidate elements for fusion, k = no. of elements resulting from fusion, savings due to fusion will be (n – k ) / n Best case if k = 1, i.e., fusion creates a single element Given an undirected graph G = (V,E) (fusion graph) V = {Candidate elements} E = {(u,v) | u, v are elements and CanMerge (u, v) is true} Finding largest set of elements that can be fused together = Finding maximum clique in G Well-known NP-Complete problem 13

9. Deployment-time Fusion Approach Maximum Clique • Enumerate all maximal cliques • NP-Hard; O(3n/3) time complexity • Our approach • Use modified Bron-Kerbosch (BK) algorithm to enumerate maximal cliques • Fastest known algorithm • Use domain-specific heuristics • Stop enumeration after first maximal clique • Remove vertices & repeat (safe due to characteristics of BK) • Only use elements which occur equal number of times as candidates (for component fusion only) Maximal Clique

10. Motivating Application • US Navy Shipboard Computing System • Consists of 150 components – 10 “operational strings” with 15 components each; deployed across 5 nodes • Sensors – Periodically sends information to the planners • System Monitors – Publish information about health of system • Planners – Process sensor & system monitor input • Effectors – Carry out planner-specified actions

11. Component Fusion Algorithms (1/2) • Two variants for component fusion • Local Component Fusion • Global Component Fusion • Local Component Fusion • Operates at the scope of a single deployment plan • Input • Set of components deployed into each collocation group on every node of a single deployment plan • Output • Physical assemblies • Modified assembly & deployment plan

12. Component Fusion Algorithms (2/2) • Global Component Fusion • Operates at the scope of all deployment plans of a single application • Set of components that are fused together spans multiple deployment plans • Merges the individual deployment plans into a unified deployment plan

13. Key Artifact of Component Fusion: Physical Assembly • Physical Assembly • Created from the set of components that are deployed within a single process of a target node • Subject to various constraints, e.g., • No two ports of the set of components should have the same name • No changes to individual component implementations • Physical Assembly indistinguishable to external clients • All valid operations on individual components are still valid

14. Prototype Implementation • Physical Assembly Mapper (PAM) • Uses the application model as the input • Exploits knowledge of platform semantics to rewrite the input model to a functionally equivalent output model • Generates middleware glue-code • Generates deployment configuration files • Operates just before deployment • Can be viewed as a “deployment-time compiler optimizer”

15. Applying Component Fusion to Shipboard Computing • Creates multiple physical assemblies • Creates multiple component attributes corresponding to individual component attributes • Maintains the same number of connections

16. Footprint Experiments Setup • Experiments were conducted using ISISlab • Five nodes running Windows XP SP2 • CIAO Version 0.5.10 used as baseline for comparison • Two kinds of footprint measurements • Static – Code & Static Data • Dynamic – Heap Memory used • Use vadump.exe to take a snapshot of working set of process hosting components • Measure number of private & shareable pages

17. Footprint Results (1/2) Total Static Footprint Total Dynamic Footprint 31% reduction 18% reduction 49% reduction 45% reduction Node Specific Dynamic Footprint Node Specific Static Footprint

18. Footprint Results (2/2) Total Footprint 18% reduction 45% reduction • Increased footprint reduction with Global vs. Local component fusion due to • More opportunities for merging components • Creation of consolidated deployment plan • Applicable to more than the internal components of an assembly • Reduces the overhead due to factory objects as well as components Component Fusion reduces the footprint significantly

19. Concluding Remarks • Our research • Describes a model-driven approach to deployment-time optimizations • Two algorithms • Local and Global component fusion • Implemented via the Physical Assembly Mapper (PAM) • PAM’s deployment-time optimization techniques • Resulted in a 45% decrease in footprint compared to conventional middleware technologies Tools can be downloaded from www.dre.vanderbilt.edu/CoSMIC/

20. Thank you!