1 / 18

Arvind S. Krishna, Aniruddha S. Gokhale , Douglas C. Schmidt

Context-Specific Middleware Specialization Techniques for Optimizing Software Product-line Architectures. Arvind S. Krishna, Aniruddha S. Gokhale , Douglas C. Schmidt Institute for Software Integrated Systems, Dept of EECS Vanderbilt University Nashville, TN, USA

nerina
Download Presentation

Arvind S. Krishna, Aniruddha S. Gokhale , Douglas C. Schmidt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Context-Specific Middleware Specialization Techniques for Optimizing Software Product-line Architectures Arvind S. Krishna, Aniruddha S. Gokhale, Douglas C. Schmidt Institute for Software Integrated Systems, Dept of EECS Vanderbilt University Nashville, TN, USA Venkatesh P. Ranganath, John Hatcliff Dept of Computer and Information Sciences Kansas State Univ Manhattan, KS, USA Eurosys’06, Leuven, Belgium April 18-21, 2006

  2. Middleware for Product Line Architectures F/A 18 product variant A/V 8-B product variant UCAV product variant F-15 product variant Product-line architecture Distribution Middleware Host Infrastructure Middleware OS & Network Protocols Hardware (CPU, Memory, I/O) Air Frame FLIR AP HUD GPS Nav IFF Domain-specific Services Common Middleware Services • Middleware factors out many reusable general-purpose & domain-specific services from traditional DRE application responsibility • Essential for product-line architectures (PLAs) • e.g., Boeing Boldstroke Avionics mission computing PLA for Boeing fighter aircrafts (F-15, F/A-18, AV-8B, UCAV/JUCAS) • DRE system with 100+ developers, 3,000+ software components, 3-5 million lines of C++ • Used as open experimentation platform

  3. Middleware for Product Line Architectures F/A 18 product variant A/V 8-B product variant UCAV product variant F-15 product variant Product-line architecture Distribution Middleware Host Infrastructure Middleware OS & Network Protocols Hardware (CPU, Memory, I/O) Air Frame FLIR AP HUD GPS Nav IFF Domain-specific Services Common Middleware Services • Middleware factors out many reusable general-purpose & domain-specific services from traditional DRE application responsibility • Essential for product-line architectures (PLAs) • However, standards-based, general-purpose, layered middleware is not yet adequate for the most demanding & mission-critical PLA-based DRE systems

  4. Middleware for Product Line Architectures F/A 18 product variant A/V 8-B product variant UCAV product variant F-15 product variant Product-line architecture Specialized Middleware OS & Network Protocols Hardware (CPU, Memory, I/O) Air Frame FLIR AP HUD GPS Nav IFF • Middleware factors out many reusable general-purpose & domain-specific services from traditional DRE application responsibility • Essential for product-line architectures (PLAs) • However, standards-based, general-purpose, layers middleware is not yet adequate for the most demanding & mission-critical PLA based DRE systems Soln: Middleware Specialization for PLA-based DRE systems

  5. Middleware Specialization Evaluation Criteria Premise • Application of specialization techniques should result in considerable improvements in QoS over & above horizontal general-purpose middleware optimizations • Handcrafting specializations infeasible for large-scale DRE systems => need for tools and processes • Specializations should have minimal impact on standards compliance (APIs) Evaluation Criteria • Use TAO (www.dre.vanderbilt.edu/TAO) as gold standard with several general-purpose optimizations • Set performance improvements ~30 to 40% improvement from application of specializations cumulatively • Turning on just one/two optimizations might improve performance by ~10 to 15%

  6. Opportunities for Middleware Specialization • Dimension #1: Specification-imposed generality • Standards-based general purpose middleware functionality defined by specifications such as CORBA, J2EE etc • Certain functionality can be excessive for PLAs • e.g., layered demultiplexing, leading to unnecessary performance overhead • Challenge: automatically remove specification-imposed generality when it’s not needed • Goal is to devise techniques that apply to any standards compliant middleware, not just an implementation 4 3 2 1

  7. Opportunities for Middleware Specialization • Dimension #2: Middleware framework generality • General-purpose middleware implementations need to work across applications that have varying functional & QoS requirements • Accommodate variability by providing hooks • e.g., for different protocol, concurrency & demultiplexing strategies • Hooks add overhead indirections & dynamic dispatching • PLAs however require one alternative; one protocol Thread-pool, Single-threaded, Thread-per connection • Challenge: Automatically specialize middleware frameworks to eliminate unnecessary hooks • Goal is devise techniques applicable to distributed systems that apply common patterns TCP/IP, VME, SCTP, SHMIOP

  8. Opportunities for Middleware Specialization • Dimension #3: Platform generality • Middleware implementations run on different hardware/OS/compiler platforms • Platforms provide certain optimizations that can be leveraged to enhance QoS • Challenge: Automatically discover PLA deployment platform characteristics to improve QoS • Goal is to devise techniques that apply to any host infrastructure middleware (e.g., ACE or JVMs) targeting heterogeneous OS, compiler, & hardware platforms gcc 3.2 (no exceptions), timesys kernel Green-hills compiler, vxWorks platform

  9. Bold Stroke PLA Scenario Goal: Select representative DRE system, e.g., “rate based” events for control information & operations that transmit common data Example PLA configuration: Basic Single Processor (BasicSP) – DRE system scenario based on Boeing Bold Stroke challenge problems from DARPA PCES & MoBIES • Timer Component – Triggers periodic refresh rates • GPS Component – Generates periodic position updates • Airframe Component – Processes input from the GPS component & feeds to Navigation display • Navigation Display – Displays GPS position updates CoSMIC/examples/BasicSP ACE_wrappers/TAO/CIAO/DAnCE/examples/BasicSP

  10. Identifying “Ahead of Time” System Invariants Specification Invariance Single method interfaces: Sends same operation on wire Framework Invariance Deployment Invariance Does not support native exceptions Protocol: A specific protocol used A specific Reactor used

  11. Feature Oriented CUStomizer (FOCUS) FOCUS addresses specialization challenges by building specialization language, tool, & process to capture & automate middleware specializations Middleware Instrumentation Phase • Capture specialization transformations via FOCUS specialization language • Annotate middleware source code with specialization directives • Create a domain-specific language (DSL) to capture middleware variability • ~1,000 Perl SLOC Parser + weaver • ~2,500 XML SLOC specialization files • ~50 (files) annotations Middleware Specialization Phase • Analyses & determines the type of specializations applicable • FOCUS transformation engineselects the appropriate transformations & uses the annotations to automate specializations

  12. Specialization Experimental Setup Goals • Application of specialization techniques should result in considerable improvements in QoS over & above horizontal general-purpose middleware optimizations • TAO baseline • Active demultiplexing & perfect hashing for O(1) request demultiplexing • Buffer caching & direct collocation optimization • Optimized configuration for different ORB components Specialized TAO Middleware • Experiment Setup • Pentium III 850 Mhz processor, running Linux Timesys 2.4.7 kernel, 512 MB of main memory, TAO version 1.4.7 compiled with gcc 3.2.3 • Timers at the client & within ORB used to collect data • Used Emulab testbed

  13. Results for Layer-folding Specialization Dim #1: Specification Imposed generality Dim #2: Framework generality Dim #3: Deployment generality Experiment • End-to-end latency measures for: • General-purpose optimized TAO with active demultiplexing & perfect hashing • Specialized TAO with layer folding specialization enabled Average path measures improved by ~40% Average end-to-end measures improved by ~16% Worst case path measure improved by ~20% Worst case end-to-end latency improved by ~14% Dispersion improves by a factor of ~1.5 for both cases • Path specialized latency measures • Path defined as code-path when a request is received until the upcall is dispatched on the skeleton Specialization applied at the server side (can also be applied at the client side)

  14. Cumulative Specialization Results Layer folding, deployment platform, memoization, constant propagation • Specification related • Layer folding • Memoization • Constant propagation (ignoring endianess) • Framework • Aspect weaving (Reactor + protocol) • Deployment • Loop unrolling + emulated exceptions Average end-to-end measures improved by ~43% Worst-case measures improved by ~45% Jitter results twice as good as general-purpose optimized TAO • End-to-end client side throughput improved by ~65%. • Results exceeded the hypothesis & evaluation criteria

  15. Evaluating FOCUS Pros & Cons Drawbacks • Doesn’t provide full-fledged language parser, i.e., join points identified via annotations or via regular expressions • Need to synchronize annotations with specialization files, so modifying source code requires change to specialization files • Ameliorated via distributed continuous QA; Limitation exists even with aspects • Correctness of transformations have to be validated externally; unlike AspectJ • Need higher level tools to validate combinations of specializations Strengths • Provides a lightweight, zero (run-time) overhead middleware specialization • Designed to work across different languages (e.g., Java & C++) • KSU applying FOCUS & specializations to Java ORBs • XML-based rule capture • Easy language extension, ability to add new features easily • If/when C++ aspect technologies mature, can transform them into aspect rules via XSLT transforms • Execute transformations via scripting • Integration with QA tools; code generation from models FOCUS available in latest ACE+TAO distribution in ACE_wrappers/bin/FOCUS

  16. Model-Driven Technologies Domain-Specific Modeling Languages Future Work System Optimizations • FOCUS approach applied to middleware optimizations • Future work will focus on identifying system level (middleware, platform, application) specializations • Goal is to drive the specialization process to optimize systems layer-to-layer • Capturing invariants in models and using generative technologies to drive specializations • Other QoS parameters

  17. F/A 18 product variant A/V 8-B product variant UCAV product variant F-15 product variant Domain-specific Services Product-line architecture Distribution Middleware Host Infrastructure Middleware OS & Network Protocols Hardware (CPU, Memory, I/O) Concluding Remarks • Resolving the tension between • Generality Middlewareis designed to be independent of particular application requirements • Specificity PLAs are driven by the functional & QoS requirements for each product variant (using SCV analysis) Common Middleware Services Specialized Middleware Stack • Development of reusable specialization patterns • Identifying specialization points in middleware where patterns are applicable • Domain-specific language (DSL) tools & process for automating the specializations • Latency improvements of 45% • www.dre.vanderbilt.edu

  18. QUESTIONS ?

More Related