Physical Assembly Mapper - PowerPoint Presentation

Slide1

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

Slide2

Context: Distributed Real-time & Embedded (DRE) SystemsStringent Quality-of-Service (QoS) demands, e.g., real-time constraintsSimultaneous execution of multiple applications with varying importance Operate under limited resourcese.g., avionics mission computingHighly heterogeneous platform, language & tool environmentse.g., Total Shipboard Computing Environment (TSCE)Use COTS middleware technologies

CORBA, RT-JavaUse COTS Component/Service-oriented technologiesCORBA Component Model (CCM), EJB, Web Services

2Slide3

3Research Challenge : System Optimization (1/2)Context

Component middleware allows designing systems that areHierarchical, i.e., individual components easily combined to form assemblies

Reusable, i.e., each component can be used in multiple composition contextsConsequences of hierarchy & reusability

Systems with large number of components Slide4

4Research Challenge : System Optimization (2/2)Problem

Systems with large number of components tend to exhibitFootprint overhead due to auxiliary middleware infrastructure in certain composition contexts

e.g., component factories/ contexts when the components are collocatedLatency overhead due to sub-optimal configuration of middleware

e.g., latency between components placed in different containersSlide5

5Component Middleware Optimization Landscape

Middleware tries to optimize execution for every applicationCollocated method invocations

Optimize the (de-)marshaling costs by exploiting localitySpecialization of request path by exploiting protocol properties

Caching, Compression, various encoding schemesReducing communication costs

Moving data closer to the consumers by replication

Reflection-based approachesChoosing appropriate alternate implementations at run-timeSlide6

6Related Research

Category

Related 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.Slide7

7Related Research: What’s missing?Design-time approachesLack high-level notation to guide optimization frameworks

Missing AST of applicationLack application context information available only at deployment-time

Optimizations restricted to information known at design-timeRequire inputs from designers, i.e., requires changes to applications and/or middlewareSlide8

Related Research: What’s missing?Runtime approachesReflective approaches, dynamic reconfiguration Add additional overhead in the critical pathNot suitable for all DRE systems

Intrusive, i.e., not completely application transparente.g., requires providing multiple implementations

Deployment-time approachesFocus on only one dimension, e.g., performance effects of binding selection

8Slide9

9Composition overhead in large-scale systems

Blind adherence to platform semanticsInefficient 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 ChallengesSlide10

Solution Approach: Deployment-time FusionNew class of optimization techniques – deployment-time fusionMerges multiple elements, e.g., components, QoS policies, into a semantically equivalent elementDifferences in fusion techniquesType of elements fused

Scope of fusionRules governing fusione.g., Component Fusion

Merges multiple components into a single component subject to fusion constraints

10Slide11

Characteristics of Deployment-time Fusion (1/2)11If n = no. of candidate elements for fusion, k

= no. of elements resulting from fusion, savings due to fusion will be (n – k ) / nBest 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}Slide12

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 ) / nBest 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 GWell-known NP-Complete problem

12Slide13

Deployment-time Fusion ApproachEnumerate all maximal cliquesNP-Hard; O(3n/3) time complexityOur approach

Use modified Bron-Kerbosch (BK) algorithm to enumerate maximal cliquesFastest known algorithmUse domain-specific heuristicsStop 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)

13

Maximum Clique

Maximal CliqueSlide14

Motivating ApplicationUS Navy Shipboard Computing SystemConsists of 150 components – 10 “operational strings” with 15 components each; deployed across 5 nodesSensors – Periodically sends information to the plannersSystem Monitors – Publish information about health of systemPlanners – Process sensor & system monitor inputEffectors – Carry out planner-specified actions

14Slide15

Candidate Elements15Slide16

Fusion Graph (Instance Level)16Slide17

Fusion Graph (Type Level)17Slide18

Fusion Graph (PAM)18Slide19

Output Cliques 19Slide20

Component Fusion Algorithms (1/2)Two variants for component fusionLocal Component FusionGlobal Component FusionLocal Component FusionOperates at the scope of a single deployment plan20Slide21

Component Fusion Algorithms (1/2)Two variants for component fusionLocal Component FusionGlobal Component FusionLocal Component FusionOperates at the scope of a single deployment planInput Set of components deployed into each collocation group on every node of a single deployment plan

OutputPhysical assemblies Modified assembly & deployment plan

21Slide22

Component Fusion Algorithms (2/2)Global Component FusionOperates at the scope of all deployment plans of a single applicationSet of components that are fused together spans multiple deployment plansMerges the individual deployment plans into a unified deployment plan

22Slide23

Component Fusion Algorithms (2/2)Global Component FusionOperates at the scope of all deployment plans of a single applicationSet of components that are fused together spans multiple deployment plansMerges the individual deployment plans into a unified deployment planGlobal vs. Local

Increased scope increases chances of creating larger physical assemblies

23Slide24

Key Artifact of Component Fusion: Physical Assembly24

Physical AssemblyCreated 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 nameNo changes to individual component implementations

Physical Assembly indistinguishable to external clientsAll valid operations on individual components are still validSlide25

Prototype Implementation25

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-codeGenerates deployment configuration files

Operates just before deploymentCan be viewed as a “deployment-time compiler optimizer”Slide26

Applying Component Fusion to Shipboard ComputingCreates multiple physical assembliesCreates multiple component attributes corresponding to individual component attributesMaintains the same number of connections

26Slide27

Footprint Experiments SetupExperiments were conducted using ISISlabFive nodes running Windows XP SP2CIAO Version 0.5.10 used as baseline for comparisonTwo kinds of footprint measurementsStatic – Code & Static DataDynamic – Heap Memory used Use vadump.exe to take a snapshot of working set of process hosting componentsMeasure number of private & shareable pages

27Slide28

Footprint Results (1/2)28

Node Specific Static Footprint

Node Specific Dynamic Footprint

Total Static Footprint

Total Dynamic Footprint

31% reduction

49% reduction

18% reduction

45% reductionSlide29

Footprint Results (2/2)Increased footprint reduction with Global vs. Local component fusion due toMore opportunities for merging componentsCreation of consolidated deployment planApplicable to more than the internal components of an assemblyReduces the overhead due to factory objects as well as components

29

Component Fusion reduces the footprint significantly

Total Footprint

18% reduction

45% reductionSlide30

Applicability of Component Fusion Techniques30Opacity of object referencesComponents don’t rely on specific details of object references, e.g., location of type information

Allows replacing references transparent to component implementationse.g., both EJB & Web Services share notion of opaque object/service referencesSlide31

Applicability of Component Fusion Techniques31Opacity of object referencesComponents don’t rely on specific details of object references, e.g., location of type information

Allows replacing references transparent to component implementationsPresence of a component context

Components access ports of other components using a context objectAllows 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

Executors

Executors

POA

EnterpriseComponent

CCMContext

Container

Servant

Component

Specific

Context

CCMContext

Main

Component

Executor

Executors

Executors

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

Internal

InterfacesSlide32

Applicability of Component Fusion Techniques32Opacity of object referencesComponents don’t rely on specific details of object references, e.g., location of type information

Allows replacing references transparent to component implementationsPresence of a component context

Components access ports of other components using a context objectAllows replacing context transparent to component implementations

Clean separation between glue-code & component implementationAllows modifications transparent to component implementations

Techniques are broadly applicable across different middlewareSlide33

Concluding Remarks33

Tools can be downloaded from www.dre.vanderbilt.edu/CoSMIC/

Our research

Describes a model-driven approach to deployment-time optimizationsTwo algorithmsLocal and Global component fusion Implemented via the Physical Assembly

Mapper (PAM)

PAM’s deployment-time optimization techniquesResulted in a 45% decrease in footprint compared to conventional middleware technologiesSlide34

Thank you!34