OPTEML: Optimization Techniques for Enhancing Middleware Quality of Service for Product-line Architectures Final Dissertation Defense, November 23rd,

OPTEML: Optimization Techniques for Enhancing Middleware Quality of Service for Product-line Architectures Final Dissertation Defense, November 23rd, 2005 Arvind S. Krishna Institute for Software Integrated Systems Vanderbilt University Nashville, Tennessee

Presentation Road Map Technology Context Research Challenges
Middleware Specialization Techniques Applying Specializations to PLAs & Middleware – A Case Study Feature Oriented Customizer (FOCUS) for Automating Specializations Experimental Results Lessons Learned & Future Work

Motivation Air Frame Air Frame AP Nav HUD GPS IFF FLIR Cyclic Exec A/V-8B Air Frame Cyclic Exec AP Nav HUD IFF F/A-18 Air Frame AP Nav HUD GPS IFF FLIR Cyclic Exec UCAV AP Nav HUD IFF Cyclic Exec F-15 FLIR FLIR GPS GPS Legacy distributed real-time & embedded (DRE) systems have historically been: Stovepiped Proprietary Brittle & non-adaptive Expensive Vulnerable Consequence: Small HW/SW changes have big (negative) impact on DRE system QoS & maintenance

Product-line architecture
Motivation F-15 product variant A/V 8-B F/A 18 UCAV Product-line architecture Air Frame FLIR AP HUD GPS Nav IFF Domain-specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware OS & Network Protocols Hardware (CPU, Memory, I/O) Middleware factors out many reusable general-purpose & domain-specific services from traditional DRE application responsibility Essential for product-line architectures (PLAs)

Product-line architecture
Motivation F-15 product variant A/V 8-B F/A 18 UCAV Product-line architecture Air Frame FLIR AP HUD GPS Nav IFF Domain-specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware OS & Network Protocols Hardware (CPU, Memory, I/O) 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 Arvind, is it not yet suitable for DRE systems or DRE PLAs. Arvind, I think it’s “PLA-based DRE systems” I ask this because PLA is our focus & the context is DRE systems.

Motivation My research optimizes middleware for PLA-based DRE systems
product variant A/V 8-B F/A 18 UCAV Product-line architecture Air Frame FLIR AP HUD GPS Nav IFF Customized Middleware OS & Network Protocols Hardware (CPU, Memory, I/O) 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 My research optimizes middleware for PLA-based DRE systems

Overview of Research Challenges
Resolving the tension between Generality  Middleware is designed to be independent of particular application requirements F-15 product variant A/V 8-B F/A 18 UCAV Product-line architecture Specificity  PLAs are driven by the functional & QoS requirements for each product variant Domain-specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware OS & Network Protocols Hardware (CPU, Memory, I/O) Standards-based, General-purpose, Layered Middleware Architecture Customized Middleware Stack Research Challenges

Research Challenges Addressed in OPTEML
1. Middleware fine-grain componentization challenges Asynchrony Policy-driven middleware componentization 2. Configuration evaluation & validation challenges 3. Specialization challenges Arvind, please at least speak what this acronym means! Arvind: Ok In the title I will emphasize what OPTEML is and also say it again on this slide. Also, please replace the diagrams of the ORBs on the left/right-hand corners with the same icons you used on the previous slide to indicate “general purpose” & “specialized” middleware. In general, make sure that you are consistent with your icons throughout the talk – otherwise, it will be confusing to people. For example, I thikn you have similar inconsistencies on slide 12. Arvind: Ok. I have re-drawn the figures in all the slides. Model-driven Distributed Continuous Quality Assurance Techniques

Challenge #3: 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

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

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 discovery 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

Crosscutting research theme: Specialization automation Hand-crafting specializations infeasible for large-scale DRE systems Thus, we need languages, processes, & tool support to automate middleware specializations gcc 3.2 (no exceptions), timesys kernel Our experimentation platform: Boeing Bold Stroke Avionics mission computing PLA for Boeing fighter aircraft e.g., 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 for many DARPA programs 4 3 2

Related Research Category Related Research Automatic language mechanisms T. Mogensen & A. Bondorf, “Logimix: A Self-Applicable Partial Evaluator for Prolog”, Program Evaluation & Program Specialization conference (PEPM), 1993 S.M. Abramov, “A Compiler Based on Partial Evaluation”, Problems of Applied Mathematics & Software Systems, Moscow State University Press, Domain: Operating Systems Massalin et al. “The Synthesis Kernel”, Computing Systems Journal, 1998 Pu et al. “Optimistic Incremental Specialization: Streamlining a Commercial Operating System”, SOSP 95 Compilers & code optimizers Yotov et al. “A Comparison of Empirical & Model Driven Optimizations”, PLDI 2003 Domain: Feature oriented specialization Zhang et al. “Towards Just in Time Middleware”, Aspect Oriented Software Engineering, (AOSD 2005), Chicago, 2004 Zhang et al. “Resolving Feature Convolution in Middleware”, ACM SIGPLAN OOPSLA Conference, Vancouver, Canada 2004 Pluggable Middleware GOPI Middleware ( PoliORB ( Current research on specializations does not address how techniques & tools can be applied to middleware to improve QoS

Research Contributions: Middleware Specialization Catalog
Specification-imposed specializations Layer-folding Constant propagation Memoization Framework specializations Aspect Weaving techniques Bridge Reactor Template method  Protocol Strategy Messaging, Wait, Demultiplexing Development of reusable specialization patterns Arvind, please fix this ORB diagram to be consistent with the other diagrams earlier! Deployment platform specializations Unroll copy loops Use emulated exceptions Leverage zero-copy data transfer buffers Identifying specialization points in middleware where patterns are applicable Domain-specific language (DSL) tools & process for automating the specializations

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

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 Arvind, please fix this ORB diagram to be consistent with the other diagrams earlier! Protocol: A specific protocol used A specific Reactor used

Specializing Dispatch Resolution
Dim #1: Specification Imposed generality Dim #2: Framework generality Dim #3: Deployment generality Invariants The same operation is invoked on a given connection Normal layered path Request Processing Paths Normal layered path Uses general-purpose optimization for request lookup Optimized fast path  Bypasses middleware layers to directly perform operation invocation ~15 processing steps across three layers in ACE+TAO middleware Optimized Fast path processing This specializations is an example of Memoization + Layer-folding specialization, where a pre-computed result is cached & used to bypass middleware layers

Specializing Reactor Component
Dim #1: Specification Imposed generality Dim #2: Framework generality Dim #3: Deployment generality Invariants Middleware components, such as Reactor and protocol components remain same for a PLA scenario Select Reactor select () Reactor_Impl WFMO_Reactor Thread_Pool Reactor Reactor Framework Reactor separates event detection from demultiplexing; ~5,000 LOC across ACE+TAO modules Applies bridge pattern to support different reactors Specialize Bridge Pattern Remove indirection, e.g., Reactor_Impl base class completely (all virtual methods concrete) No changes to component interface & doesn’t break compatibility This specialization is an example of Aspect Weaving specialization, where crosscutting middleware features are customized

Deployment Platform Specializations
Dim #1: Specification Imposed generality Dim #2: Framework generality Dim #3: Deployment generality Invariants Hardware, OS, & compiler characteristics do not change Deployment Platform Generality Platform characteristics affect QoS TANGO Timesys linux + gcc ACE vxWorks + Greenhills compiler Certain versions of gcc do not support exceptions Specialize Middleware for Deployment platform Empirically (via benchmarks) determine the right set hardware, OS & compiler characteristics suitable for the deployment platform (similar to research done by Yotov et.al) This specialization is a variation of Constant Propagation where the constant (platform characteristic) is used to tailor the middleware

Overview of 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 engine selects the appropriate transformations & uses the annotations to automate specializations

Comparing FOCUS with Related Work
Category Related Research Aspect Oriented Mechanisms Kiczales, “An Overview of AspectJ”, Lecture Notes in Computer Science, 1999 Lohmann et al. “Generative Programming with Aspect C++”, GPCE 2004, Vancouver, Canada Todd Veldhuizen “Using C++ meta programs”, C++ Report 1999 Transformational approaches Ira Baxter “Design Maintenance System”, Semantic Designs Inc, Stratego-XT ( Template code generation approaches Jostraca ( Java Emitter Templates ( FOCUS Characteristics FOCUS design motivated by template code-generation approaches & generative programming techniques Allows annotations to be directly placed in code (placed as special comments) Annotations explicitly identify variability; support evolution A light-weight specialization approach (does not implement a full-blown language parser)

FOCUS Research Goals Domain specific language for capturing specializations; minimize accidental complexity Ensuring transformations (1) do not incur additional overhead; (2) do not compromise portability Develop a process that enables role separation Process to support specialization with evolution Applying specializations improve latency ~30 – 40% Language agnostic; leverage annotations Contributions: The goal of this work isn’t on specialization languages per se, but instead to quantify the improvements that come from applying various types of specializations to middleware Transformational approaches: Stratego-XT, DMS support a broader range of specializations

FOCUS Specialization Language (FSL)
FOCUS uses an XML DTD to create a DSL for capturing specializations Capability to perform code substitutions Devirtualize interfaces Replace base classes with derived class FSL Approach <substitute>: Capability to do <search> … <replace> on code Capability to specialize base implementations Framework specialization requires code to be copied from derived to base classes FSL Approach <copy-from-source>: Copy code from a specific point to a specific point between different files <start-hook>  start copying <end-hook>  hook to stop copying <dest-hook>  destination Capability to weave code at specified points The layer folding specializations require code to be woven in along the request processing path FSL Approach <add>: <hook> that specifies the annotated point; <data> where data is specified FSL <substitute> <search>ACE_Reactor_Impl</search> <replace>ACE_Select_Reactor_Impl</replace> </substitute> <copy-from-source> <source>Select_Reactor.h</source> <copy-hook-start>HOOK-START </copy-hook-start> <copy-hook-end>HOOK-END </copy-hook-end> <dest-hook>HOOK-COPY</dest-hook> </copy-from-source> <add> <hook>FORWARD_DECL</hook> <data>#include “Select_Reactor.h”</data> <add>

FOCUS Specialization Phase
Annotations help identify join points Annotated middleware source Transformed middleware source //File: Reactor.h REACTOR_SPL_INCLUDE_HOOK class Reactor { public: virtual int run_reactor_event_loop (); // Other public methods .... private: ACE_Reactor_Impl *reactor_impl_; // }; //File: Reactor.h REACTOR_SPL_INCLUDE_HOOK // Code woven by FOCUS: #include "ace/Select_Reactor.h" // END Code woven by FOCUS class Reactor { public: int run_reactor_event_loop (); // Other public methods .... private: ACE_Select_Reactor *reactor_impl_; // End Code woven by FOCUS // }; #include concrete header file Arvind, the points I made at the bottom here are VERY important to emphasize in your paper(s)/talk(s). Removed virtual keyword Replaced ACE_Reactor_Impl with ACE_Select_Reactor These specializations don’t affect framework “business logic,” just its structure Existing framework is still available when developers need OO capabilities

Automating Layer Folding Specialization
Dim #1: Specification Imposed generality Dim #2: Framework generality Dim #3: Deployment generality Automating Specialization via FOCUS On a per connection basis determine the target dispatcher; For subsequent requests, directly use the dispatcher to process requests Normal path; the dispatch is cached in the process <add> <hook>TAO_DISPATCH_OPT_ADD_HOOK</hook> <data> 1. if (__dispatch_resolved__) 2.{ 3: //First invocation normal path 4: __dispatch_resolved_ = 1; 5: } 6: else 7:{ // All invocations go through --- Optimized path 8: this->request_disaptcher__.dispatch (…) 9:} </add> FOCUS enables specification of specializations in corresponding language syntax Directly use cached dispatcher Component Source Files {h,cpp} (loc) FOCUS Specialization file Layer folding Demultiplexing (tao, PortableServer) tao/GIOP_Base  1,200 PortableServer/Servant_Base  2,000 <add>, <substitute>, <comment> Specialization file ~250 loc Tag related changes (5 locations) in TAO & Portable Server

Automating Reactor Specialization
Dim #1: Specification Imposed generality Dim #2: Framework generality Dim #3: Deployment generality <add> <hook>TAO_REACTOR_SPL_COMMENT_HOOK_END</hook> <data> ACE_NEW_RETURN (impl, ACE_Select_REACTOR (….), 0); </data> Automating Specialization via FOCUS <substitute>,<add>: weave code that creates specialized Reactor <copy-from-source> to move implementation from Select_Reactor to base Reactor component <comment>: comment unspecialized code Transformations preserve hooks; Minimizes clutter in middleware source ACE_Reactor_Impl * TAO_Advanced_Resource_Factory::allocate_reactor_impl (void) const { ACE_Reactor_Impl *impl = 0; TAO_REACTOR_SPL_COMMENT_HOOK_START switch (this->reactor_type_) ………… } TAO_REACTOR_SPL_COMMENT_HOOK_END Component Source Files {h,cpp} (loc) FOCUS Specialization file Aspect Weaving Reactor Framework (ACE, TAO modules) ace/Reactor  1,500 ace/Reactor_Base 1,800 ace/Select_Reactor 2,500 tao/advanced_resouces  2,500 <add>, <substitute>, <copy-from-source> <comment> Specialization file ~700 loc Tag related changes (10 locations) < 0.1% of the code within the Reactor framework

Automating Platform Specializations
Dim #1: Specification Imposed generality Dim #2: Framework generality Dim #3: Deployment generality Deployment platform specialization Exception support: Autoconf’s AC_COMPILE_IF_ELSE macro to check if compiler supports native exception Loop unrolling optimization Autoconf’s AC_RUN_IF_ELSE macros to compile & run benchmark to quantify memcpy() performance improvements Provide actual source language that will be compiled & run Variable that will be checked to set a compilation flag ACE_CACHE_CHECK([if ACE memcpy needs loop unrolling], [ace_cv_memcpy_loop_unroll], [AC_RUN_IFELSE([AC_LANG_SOURCE([[ /// …. Program that will run the benchmark to //// determine if an optimization is better Directive to run the benchmark Component Source Files {h,cpp} (loc) FOCUS Specialization file Constant Propagation (autoconf) ace/CDR_Stream  4,000 ace/Message_Block 2,000 Code changes ~650 Benchmark ~250 This approach can be applied automatically to discover OS-specific system calls & compiler settings that maximize QoS

Evaluating FOCUS Pros & Cons
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 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 Arvind, for your Ph.D. talk, you’ll need to give a bunch more examples of how you’ve applied various sorts of specializations (i.e., not just FOCUS, but also the autoconfig stuff) & how these various specializations have improved performance. FOCUS available in latest ACE+TAO distribution in ACE_wrappers/bin/FOCUS

Specialization Evaluation Criteria
Hypothesis Application of specialization techniques should result in considerable improvements in QoS over & above horizontal general-purpose middleware optimizations Termination Criteria (from Qualifying exam) Use TAO as gold standard (widely used production DRE middleware) 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% On slide 19 I recommend that you first say what your "hypotheses" were, & then summarize your results so that people will know that you met your goals. Arvind: I moved the slide here before the empirical results. I have also separated the hypothesis with the termination criteria. TAO baseline Active demultiplexing & perfect hashing for O(1) request demultiplexing Buffer caching & direct collocation optimization Optimized configuration for different ORB components Experiment Setup Pentium III 850 Mhz processor, running Linux Timesys kernel, 512 MB of main memory, TAO version compiled with gcc 3.2.3 Timers at the client & within ORB used to collect data

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)

Aspect Weaving Specialization Results
Dim #1: Specification Imposed generality Dim #2: Framework generality Dim #3: Deployment generality Experiment Client/server communicate by sending a simple long End-to-end latency measures for: General-purpose optimized TAO and Reactor, Protocol frameworks specialized with FOCUS compared Average Measures: Reactor 4.5% Protocol: 5% Jitter better; specialization does not compromise predictability Result Synopsis Average latency improves by ~5% for both protocol & reactor specializations Specialization also applied to other frameworks in TAO: Messaging, Wait Strategies Worst case measures improved compared to general-purpose TAO Jitter improves, though not considerably 99% values closer to average & worst-case values are better indicating better predictability

Results for Autoconf Specialization
Dim #1: Specification Imposed generality Dim #2: Framework generality Dim #3: Deployment generality Average latency improves ~17% Deployment platform specialization Exception support: Loop unrolling optimization During ORB configuration, autoconf used to use emulated exceptions & loop unrolling optimization Predictability improved over general-purpose middleware Worst-case measures improve by ~50 µs Future research will extend research on these empirical optimizations to more model-driven approaches for performance prediction

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 & termination criteria from Qualifying exam!

TAO uses active demultiplexing & perfect hashing for O(1) demux time
Lessons Learned (1/2) Need to document specialization interplay Specializations applied such that no dependencies/conflicts exists As more specializations are developed it is necessary to document dependencies between specializations QoS benefits implementation specific Optimizations improve QoS over & above general-purpose optimizations Other ORBs, e.g., JacORB, do not use such optimizations; performance gains in this case would be more Preliminary results [Daugherty] on ZEN show that speed up was better compared to TAO TAO uses active demultiplexing & perfect hashing for O(1) demux time Arvind, please fix this ORB diagram to be consistent with the other diagrams earlier! [Daugherty] Gary Daugherty, A Proposal for the Specialization of HA/DRE Systems, ACM PEPM 04

Specializations increase slack in the system
Lessons Learned (2/2) Specializations have potential to improve task schedulability Specializations help high priority tasks finish ahead of their time to complete Tasks with priority 50 finish early, increasing time available for scheduling priorities with 35 & 10 Specializations can benefit both hard real-time & soft & softer real-time tasks Specializations increase slack in the system POA S1 S2 POA S3 20 S4 35 POA S5 40 50 Adaptation with specializations can adversely affect QoS Specializations do not consider any form of recovery if invariance assumptions fail Adaptation requires loading general-purpose code, add checks along request processing path; increases jitter for DRE systems

Summary of Research Publications
Contributions My Publications & Acceptance rates Fine-grain Componentization of Middleware Architecture Book Chapter: Middleware for Communications, Wiley, NY, 2004 International Conference on Distributed Systems (ICDCS) 2004 (17%) Real-time Application Symposium (RTAS) 2003 (25%) Distributed Objects & Applications (DOA) 2002 (25%) Distributed Objects & Applications (DOA) 2003 (30%) Pattern Languages of Program (PloP) 2005 Submitted to IEEE Transactions on Parallel and Distributed Systems Middleware Configuration Validation & Selection International Conference on Software Engineering (ICSE) 2005 (10-15%) RTAS 2005 (30 %) International Conference on Software Reuse (ICSR) (22%) Elsevier Science of Computer Programming, International Journal of Embedded Systems (invited submission) IEEE Software Studia Infomatica Universalis Journal Software Process: Improvement & Practice Journal Benchmarking & Performance Evaluation Real-time Application Symposium (RTAS) 2004 (27%) (selected as Best of RTAS 2004) Springer-Verlag Real-time Systems Journal Middleware Specialization MODELS 2005 Workshop on PLAs RTSS 2005 Work in Progress Session Submitted to the ACM SIGOPS Eurosys Conference First Author Second Author Third Author

Future Work System Optimizations
Model-Driven Technologies Domain-Specific Modeling Languages OPTEML focused on 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

Questions? Acknowledgments PhD Dissertation Committee
Dr. Andy Gokhale, Dr. Gabor Karsai Dr. Adam Porter, Dr. Douglas Schmidt, Dr. Janos Sztipanovits Research Collaborators Gary Daughertry, Dr. John Hatcliff, Dr. Raymond Klefstad, Dr. Atif Memon, Dr. Venkatesh Ranganath, Diego Sevilla Ruiz, Dr. Michael Stal, Dr. Cemal Yilmaz DOC Alumni Dr. Angelo Corsaro, Balachandran Natarajan, Ossama Othman, Dr. Carlos O’ Ryan, Dr. Nanbor Wang Friends and Family Arvind, for your final presentation you might want to list the “Acknowledgements” at the end!

Backup

Summary of Research Contributions
Area Contributions General-purpose optimization techniques Patterns & techniques for developing fine-grain componentized middleware architectures Policy-driven middleware customization approaches Configuration-driven optimization techniques Domain-specific modeling language (DSML) to capture QoS evaluation concerns for component middleware & PLAs Specialization optimization techniques Specialization patterns for enhancing middleware QoS FOCUS: A tool-driven approach for middleware specialization Preserving & validating middleware configuration properties MDD Distributed Continuous Quality Assurance (DCQA) process for preserving & validating middleware configuration properties Main-effects screening, which is a DCQA process for identifying middleware configuration main effects

Challenge #1:Componentization Challenges
Fine-grain Middleware Componentization Levels of customizability  coarse-grain vs. fine-grain componentization Policy driven approaches to fine-grain componentization Footprint  Fine-grain approach has 50% reduction compared with monolithic approach [DOA 02, 03] Performance  enables all general purpose-optimizations [RTAS 03] & real-time properties [ICDCS04] along critical path My Contributions Publications Next Generation Middleware Design Book Chapter: Middleware for Communications Wiley & Sons, New York, 2004 Real-time Performance & Predictability International Conference on Distributed Systems (ICDCS) 2004 Real-time Application Symposium (RTAS) 2003 Pluggable POA Architecture ORB Core Architecture Distributed Objects & Applications (DOA) 2002 Distributed Objects & Applications (DOA) 2003

Challenge #2: Configuration Validation
Model-Driven QA processes for configuration evaluation & validation Developed techniques for providing a reusable, automated process for evaluating impact of middleware configuration on PLA QoS [RTAS05] Addresses accidental complexities in code-generation [ICSR] Addresses validation challenges across different hosts/configurations [IEEE Software] Documents configuration main-effects that can drive customizations or further validation [ICSE 2005] Contributions Publications Configuration “main effects” (MDD & Skoll) Real-time Application Symposium (RTAS) 2005 International Conference on Software Engineering (ICSE) 2005 BGML & CoSMIC Tool Suite International Conference on Software Reuse (ICSR) Elsevier Science of Computer Programming, International Journal of Embedded Systems (Invited submission) Distributed Testing & Quality Assurance IEEE Software, Studia Infomatica Universalis Journal Your title font sizes are all over the place again. For example, look at slides 11 & 12, which are one example of inconsistencies. Please make things CONSISTENT. Arvind: I have made sure that all my title slides are of the same font

Future Work  Resolving Framework Variability
Middleware implementations accommodate variability by using patterns Greater benefits can be accrued by applying specialization approaches to other middleware frameworks e.g., locking, buffering & concurrency strategies in middleware Arvind, please fix this ORB diagram to be consistent with the other diagrams earlier!

FOCUS Instrumentation Phase
Middleware Annotations Middleware developer annotates middleware with hooks Hooks represented as “meta-comments,” i.e., opaque to compilers ACE_Reactor_Impl * TAO_Advanced_Resource_Factory::allocate_reactor_impl (void) const { ACE_Reactor_Impl *impl = 0; TAO_REACTOR_SPL_COMMENT_HOOK_START switch (this->reactor_type_) ………… } TAO_REACTOR_SPL_COMMENT_HOOK_END <?xml version='1.0'?> <transform> 11: <module="TAO/tao"> 12: <file name="advanced_resource.cpp"> 13: <comment> 14: <start-hook>TAO_REACTOR_SPL_COMMENT_HOOK_START </start-hook> 15: <end-hook>TAO_REACTOR_SPL_COMMENT_HOOK_END </end-hook> 16: </comment> 17: </file> 18: </module> 23: .... </transform> Arvind, I recommend you extend this example to multiple slides so that we can split it up in a manner so that it illustrates the annotations that correspond to all of the instrumentations you showed on the previous slides, i.e., have things match up so the FSL file & the annotations in ACE are all clearly illustrated. Annotations help identify join points & relieve FOCUS from Implementing a full fledged language parser

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 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 How can middleware frameworks be specialized to eliminate hooks in middleware? TCP/IP, VME, SCTP, SHMIOP Arvind, please fix this ORB diagram to be consistent with the other diagrams earlier!

Specializations increase slack in the system
Lessons Learned (2/2) Specializations have potential to improve task schedulability Specializations help high priority tasks finish ahead of their time to complete Tasks with priority 50 finish early, increasing time available for scheduling priorities with 35 & 10 Specializations can benefit both hard real-time & soft & softer real-time tasks Specializations increase slack in the system POA S1 S2 POA S3 20 S4 35 POA S5 40 50 Adaptation with specializations can adversely affect QoS Specializations do not consider any form of recovery if invariance assumptions fail Adaptation requires loading general-purpose code, add checks along request processing path; increases jitter for DRE systems QoS improvements are scenario specific All our specializations improve path latencies considerably than end-to-end latency; More the specialized code path is traversed, greater is QoS improvement

Applicability of Specialization Approaches
Dim #1: Specification Imposed generality Dim #2: Framework generality Dim #3: Deployment generality Resolving Specification Imposed Generality Applicable to standards compliant CORBA middleware Layer folding specialization  CORBA demultiplexing; Other layered demultiplexing approaches Avoiding (de)marshaling checks  middleware standards such as J2EE, .NET that target heterogeneous deployment 4 3 Arvind, please fix this ORB diagram to be consistent with the other diagrams earlier! 2 Little endian Big endian 1

Dim #1: Specification Imposed generality Dim #2: Framework generality Dim #3: Deployment generality Resolving Framework generality Specialize design pattern Reactor Framework specialization  Bridge pattern Protocol framework specialization  Template method pattern Techniques to distributed systems that apply these patterns ( Thread-pool, Single-threaded, Thread-per connection TCP/IP, VME, SCTP, SHMIOP Arvind, please fix this ORB diagram to be consistent with the other diagrams earlier!

Dim #1: Specification Imposed generality Dim #2: Framework generality Dim #3: Deployment generality Dimension #3: Resolving Deployment generality Host Infrastructure middleware (ACE, JVMs) targeting heterogeneous OS, compiler & hardware characteristics Systems concerned with QoS gcc 3.2 (no exceptions), timesys kernel Green-hills compiler, vxWorks platform Arvind, please fix this ORB diagram to be consistent with the other diagrams earlier!

OPTEML: Optimization Techniques for Enhancing Middleware Quality of Service for Product-line Architectures Final Dissertation Defense, November 23rd,

Similar presentations

Presentation on theme: "OPTEML: Optimization Techniques for Enhancing Middleware Quality of Service for Product-line Architectures Final Dissertation Defense, November 23rd,"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

OPTEML: Optimization Techniques for Enhancing Middleware Quality of Service for Product-line Architectures Final Dissertation Defense, November 23rd,

Similar presentations

Presentation on theme: "OPTEML: Optimization Techniques for Enhancing Middleware Quality of Service for Product-line Architectures Final Dissertation Defense, November 23rd,"— Presentation transcript:

Similar presentations

About project

Feedback