1. Physical Assembly Mapper: A Model-driven Optimization Tool for QoS- enabled Component Middleware Vanderbilt University Nashville, Tennessee Institute for Software Integrated Systems 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 2

3. 3 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 Middleware Bus Container … … …

4. 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. 5 Related Research CategoryRelated Research Design-time approaches Venkita Subramonian et. al., The design and performance of configurable component middleware for DRE systems. In Proceedings of RTSS 2004. Arvind Krishna et. al., Context-Specific Middleware Specialization Techniques for Optimizing Software Product-line Architectures. In Proceedings of EuroSys 2006 Frank Hunleth et. al., Footprint and Feature Management Using Aspect-oriented Programming Techniques. In Proceedings of LCTES 02, pages 38–45. ACM Ömer Erdem Demir et. al., An aspect-oriented approach to bypassing middleware layers. In Proceedings of AOSD 2007, pages 25–35, ACM. Charles Zhang et.al.,Towards just-in-time middleware architectures. In Proceedings of AOSD 2005, pages 63–74, ACM. Runtime approaches Ada Diaconescu et. al., Automatic performance management in component based software systems. In Proceedings of ICAC 2004, pages 214–221, IEEE. John A. Zinky et. al., Architectural Support for Quality of Service for CORBA Objects. Theory and Practice of Object Systems, 3(1):1–20, 1997. Christopher D. Gill et. al., Middleware Scheduling Optimization Techniques for DRE Systems. In Proceedings of WORDS 2002. IEEE Ronghua Zhang et. al., Controlware: A middleware architecture for feedback control of software performance. In Proceedings of ICDCS 2002,IEEE. Chenyang Lu et. al., Feedback control real-time scheduling: Framework, modeling, and algorithms. Real-Time Syst., 23(1-2):85–126, 2002. Lei Gao et. al., Application specific data replication for edge services. In Proceedings of WWW 2003, pages 449–460, ACM Press. Nirmal K. Mukhi et. al., Cooperative middleware specialization for service oriented architectures. In Proceedings of WWW 2004, pages 206–215, ACM Press. Gurdip Singh et. al., Customizing event ordering middleware for component-based systems. In Proceedings of ISORC’05, pages 359–362, IEEE Deployment-time approaches Sang Jeong Lee et.al., ISE01-4: Deployment time performance optimization of internet services. In Proceedings of GLOBECOM 2006. pages 1–6, IEEE.

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

7. 7 Related Research: What’s missing? Design-time approaches Lack high-level notation to guide optimization frameworks Missing AST of application Lack application context information available only at deployment-time Optimizations restricted to information known at design-time Require inputs from designers, i.e., requires changes to applications and/or middleware

8. Related Research: What’s missing? Runtime approaches Reflective approaches, dynamic reconfiguration Add additional overhead in the critical path Not suitable for all DRE systems Intrusive, i.e., not completely application transparent e.g., requires providing multiple implementations Deployment-time approaches Focus on only one dimension, e.g., performance effects of binding selection 8

9. 9 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 Component System Optimizations: Unresolved Challenges

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

11. Characteristics of Deployment-time Fusion (1/2) 11 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}

12. Characteristics of Deployment-time Fusion (2/2) 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 12

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

14. Deployment-time Fusion Approach Enumerate all maximal cliques NP-Hard; O(3 n/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) 14 Maximum Clique Maximal Clique

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

16. Candidate Elements 16

17. Fusion Graph (Instance Level) 17

18. Fusion Graph (Type Level) 18

19. Fusion Graph (PAM) 19

20. Output Cliques 20

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

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

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

24. 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 Global vs. Local Increased scope increases chances of creating larger physical assemblies 24

25. Key Artifact of Component Fusion: Physical Assembly 25 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

26. Prototype Implementation 26 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”

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

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

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

30. Footprint Results (2/2) 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 30 Component Fusion reduces the footprint significantly Total Footprint 18% reduction 45% reduction

31. Applicability of Component Fusion Techniques 31 Opacity of object references Components don’t rely on specific details of object references, e.g., location of type information Allows replacing references transparent to component implementations e.g., both EJB & Web Services share notion of opaque object/service references

32. Applicability of Component Fusion Techniques 32 Opacity of object references Components don’t rely on specific details of object references, e.g., location of type information Allows replacing references transparent to component implementations Presence of a component context Components access ports of other components using a context object Allows replacing context transparent to component implementations e.g., EJB has a EJBContext which is very similar to CCM’s Context Container Servant Component Specific Context CCMContext Main Component Executor Executors POA EnterpriseComponent CCMContext Container Servant Component Specific Context CCMContext Main Component Executor Executors POA EnterpriseComponent CCMContext user implemented code Container CORBA Component POA E x t e r n a l I n t e r f a c e s Interna l Interface s

33. Applicability of Component Fusion Techniques 33 Opacity of object references Components don’t rely on specific details of object references, e.g., location of type information Allows replacing references transparent to component implementations Presence of a component context Components access ports of other components using a context object Allows replacing context transparent to component implementations Clean separation between glue-code & component implementation Allows modifications transparent to component implementations Techniques are broadly applicable across different middleware

34. Concluding Remarks 34 Tools can be downloaded from www.dre.vanderbilt.edu/CoSMIC/ 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

35. Thank you! 35