DOCSLIB.ORG

The Interplay of Compile-Time and Run-Time Options for Performance Prediction Luc Lesoil, Mathieu Acher, Xhevahire Tërnava, Arnaud Blouin, Jean-Marc Jézéquel

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Interplay of Compile-Time and Run-Time Options for Performance Prediction Luc Lesoil, Mathieu Acher, Xhevahire Tërnava, Arnaud Blouin, Jean-Marc Jézéquel The Interplay of Compile-time and Run-time Options for Performance Prediction Luc Lesoil, Mathieu Acher, Xhevahire Tërnava, Arnaud Blouin, Jean-Marc Jézéquel To cite this version: Luc Lesoil, Mathieu Acher, Xhevahire Tërnava, Arnaud Blouin, Jean-Marc Jézéquel. The Interplay of Compile-time and Run-time Options for Performance Prediction. SPLC 2021 - 25th ACM Inter- national Systems and Software Product Line Conference - Volume A, Sep 2021, Leicester, United Kingdom. pp.1-12, 10.1145/3461001.3471149. hal-03286127 HAL Id: hal-03286127 https://hal.archives-ouvertes.fr/hal-03286127 Submitted on 15 Jul 2021 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. The Interplay of Compile-time and Run-time Options for Performance Prediction Luc Lesoil, Mathieu Acher, Xhevahire Tërnava, Arnaud Blouin, Jean-Marc Jézéquel Univ Rennes, INSA Rennes, CNRS, Inria, IRISA Rennes, France [email protected] ABSTRACT Both compile-time and run-time options can be configured to reach Many software projects are configurable through compile-time op- specific functional and performance goals. tions (e.g., using ./configure) and also through run-time options (e.g., Existing studies consider either compile-time or run-time op- command-line parameters, fed to the software at execution time). tions, but not both and the possible interplay between them. For in- Several works have shown how to predict the effect of run-time stance, all run-time configurations are measured using a unique ex- options on performance. However it is yet to be studied how these ecutable of the system, typically compiled with the default compile- prediction models behave when the software is built with different time configuration (i.e., using ./configure without overriding compile- compile-time options. For instance, is the best run-time configu- time options’ values). Owing to the cost of measuring configura- ration always the best w.r.t. the chosen compilation options? In tions, this is perfectly understandable but it is also a threat to valid- this paper, we investigate the effect of compile-time options on the ity. In particular, we can question the generality of these models if performance distributions of 4 software systems. There are cases we change the compile-time options when building the software where the compiler layer effect is linear which is an opportunity system: Do compile-time options change the performance distribu- to generalize performance models or to tune and measure runtime tion of run-time configurations? If yes, to what extent? Is the best performance at lower cost. We also prove there can exist an inter- run-time configuration always the best? Are the most influential play by exhibiting a case where compile-time options significantly run-time options always the same whatever the compile-time op- alter the performance distributions of a configurable system. tions used? Can we reuse a prediction model whatever the build has been? In short: (RQ1) Do compile-time options change the CCS CONCEPTS performance distributions of configurable systems? In this paper we investigate the effect of compile-time options • Software and its engineering ! Software product lines; Soft- together with runtime options on the performance distributions ware product lines; Software performance; • Computing method- of 4 software systems. For each of these systems, we measure a ologies ! Machine learning. relevant performance metrics for a combination of =12 compile =1 ¸=1 time options and =1A run-time options (yielding 2 2 A possi- ble configurations) over a number of different inputs. We show 1 INTRODUCTION that the compile-time options can alter the run-time performance An ideal software system is expected to deliver the right function- distributions of software systems, and that it is worth tuning the ality on time, using as few resources as possible, in every possible compile-time options to improve their performances. We thus ad- circumstances whatever the hardware, the operating system, the dress a second research question: (RQ2) How to tune software compiler, or the data fed as input. For fitting such a diversity of performances at the compile-time level? needs, it is increasingly common that software comes in many Our contributions are as follows : variants and is highly configurable through configuration options. • We construct a protocol and carry out an empirical study Numerous works have studied the effects of configuration op- investigating the effects of compile-time options on run-time tions on performance. The outcome is a performance model that performances, for 4 software systems, various workloads, can be used to predict the performance of any configuration, to find and non-functional properties; an optimal configuration, or to identify, debug, and reason about in- • We provide a Docker image, a dataset of measurements, as fluential options of a system [19, 23, 28, 29, 38–40, 44, 49, 53, 56, 63]. well as analysis scripts1; There are however numerous mechanisms to implement and de- • We exhibit a case (namely nodeJS and its operation rate) for liver options: configuration files, command-line parameters, feature which the compile-time options interact with the run-time toggles or flags, plugins, etc. A useful distinction to make is between options. We also present and implement a simple case of compile-time and run-time options. On the one hand, compile-time cross-layer tuning, providing a set of configuration options options can be used to build a custom system that can then be (run-time & compile-time) improving the operation rate of executed for a variety of usages. The widely used "./configure && the default configuration of nodeJS. make" is a prominent example for configuring a software project Remainder. Section2 discusses the motivation of this paper; at compile-time. On the other hand, run-time options are used to Section3 presents the experimental protocol; Section4 evaluates parameterize the behavior of the system at load-time or during the and analyses the results w.r.t. this protocol; Section5 discusses execution. For instance, users can set some values to command-line arguments for choosing a specific algorithm or tuning the execu- 1Companion repository; Zenodo data: https://zenodo.org/record/4706963; Docker: tion time based on the particularities of a given input to process. https://hub.docker.com/r/anonymicse2021/splc21 Luc Lesoil, Mathieu Acher, Xhevahire Tërnava, Arnaud Blouin, Jean-Marc Jézéquel the results, their limitations and future work; Section6 describes model has many applications and use-cases [4, 19, 22–24, 28, 29, 38– research works related to the topic of this paper; Section7 details 40, 44, 49, 53, 56, 60, 63, 65]: optimization (tuning) and finding of the threats to validity; Section8 concludes our paper. the best configuration, specialization of the configuration space, un- derstanding and debugging of the effects of configuration options, 2 BACKGROUND AND MOTIVATION verification (e.g., non-regression testing), etc. The performance of a 2.1 Compile-time and run-time options system, such as execution time, is usually measured using the same compiled executable (binary). In our case, we consider that the Many software systems are highly-configurable both at compile way the software is compiled is subject to variability; there time and at run time. For instance, the "./configure && make" is are two configuration spaces. Formally, given a software sys- widely used to build a custom system i.e., an executable binary. tem with a compile-time configuration space C and a run-time Considering the x264 video encoder (see Figure1), the compile- configuration space R, a performance model is a black-box func- time option –disable-asm can be used to disable "platform-specific tion 5 : C × R ! R that maps each run-time configuration A 2 R assembly optimizations". There are compile-time options to activate to the performance of the system compiled with a compile-time the needed functionality (e.g., –disable-avs), to fit requirements configuration 2 2 C. The construction of a performance model con- related to the hardware or operating system, etc. Some of these sists in running the system in a fixed compile-time setting 2 2 C on options have a suggested impact on performance. For the same various configurations A 2 R, and record the resulting performance subject system x264, it is also possible to use run-time options values ? = 5 ¹2, Aº. such as me, mbtree and cabac with possible effects on the size Learning performance models. Measuring all configurations of and encoding time. Run-time options are used to parameterize the a configurable system is the most obvious path to, for example, behavior of the system at load time or during the execution. find a well-suited configuration. It is however too costly or infea- sible in practice. Machine-learning techniques address this issue by measuring only a subset of configurations (known as sample) and then using these configurations’ measurements to build a per- formance model capable of predicting the performance of other configurations (i.e., configurations not measured before). Research work thus follow a "sampling, measuring, learning" process [19, 22– 24, 29, 38–40, 44, 49, 53, 60, 63, 65]. The training data for learning a performance model of a system compiled with a configuration 2 2 C is then 퐷2 = f¹R#8, P#8º j 8 2 1 : = g where = is the number of measurements. Statistical learningJ techniques,K such as linear regression [51], decision trees [48], or random forests [42], use this training set to build prediction models.
Load more

Recommended publications
  • Designing and Packaging Printer and Scanner Drivers
    Designing and Packaging Printer and Scanner Drivers OpenPrinting MC on Linux Plumbers 2020 August 28, 2020 Till Kamppeter, OpenPrinting What we had ● Printer drivers – PPD files – Filters, perhaps also backends – All has to be in CUPS-specific directories ● Scanner drivers – Shared libraries with SANE ABI in SANE-specific directories ● Packaging – Binaries were built specific to destination distro and packaged in DEB or RPM packages – For each distro drivers need to be built, packaged, and tested separately – As files need to be in specific directories drivers cannot be installed with CUPS in a Snap or with scanning user applications in Snaps What we want ● Sandboxed packaging – Snaps – Distribution-independent: Install from Snap Store on any distro running snapd – More security: Every package with all its libraries and files in its own sandbox, fine-grained control for communication between packages – All-Snap distributions ● But – You cannot drop driver files into directories of a snapped CUPS or snapped user applications, Snaps do not see the system’s files – Snaps only communicate via IP or D-Bus, not by files ● Also – CUPS is deprecating support for PPD files, working by itself only in driverless IPP mode. The New Architecture ● Printer/Scanner Applications emulating an IPP device – Easily snappable: Communicates only via IP – Multi-function device support, Printing, Scanning, and Fax Out can be done in one Snap/Application – Web admin interface for vendor/device-specific GUI – Behaves like a network printer/scanner/multi-function
    [Show full text]
  • The LLVM Instruction Set and Compilation Strategy
    The LLVM Instruction Set and Compilation Strategy Chris Lattner Vikram Adve University of Illinois at Urbana-Champaign lattner,vadve ¡ @cs.uiuc.edu Abstract This document introduces the LLVM compiler infrastructure and instruction set, a simple approach that enables sophisticated code transformations at link time, runtime, and in the field. It is a pragmatic approach to compilation, interfering with programmers and tools as little as possible, while still retaining extensive high-level information from source-level compilers for later stages of an application’s lifetime. We describe the LLVM instruction set, the design of the LLVM system, and some of its key components. 1 Introduction Modern programming languages and software practices aim to support more reliable, flexible, and powerful software applications, increase programmer productivity, and provide higher level semantic information to the compiler. Un- fortunately, traditional approaches to compilation either fail to extract sufficient performance from the program (by not using interprocedural analysis or profile information) or interfere with the build process substantially (by requiring build scripts to be modified for either profiling or interprocedural optimization). Furthermore, they do not support optimization either at runtime or after an application has been installed at an end-user’s site, when the most relevant information about actual usage patterns would be available. The LLVM Compilation Strategy is designed to enable effective multi-stage optimization (at compile-time, link-time, runtime, and offline) and more effective profile-driven optimization, and to do so without changes to the traditional build process or programmer intervention. LLVM (Low Level Virtual Machine) is a compilation strategy that uses a low-level virtual instruction set with rich type information as a common code representation for all phases of compilation.
    [Show full text]
  • Screen Capture Tools to Record Online Tutorials This Document Is Made to Explain How to Use Ffmpeg and Quicktime to Record Mini Tutorials on Your Own Computer
    Screen capture tools to record online tutorials This document is made to explain how to use ffmpeg and QuickTime to record mini tutorials on your own computer. FFmpeg is a cross-platform tool available for Windows, Linux and Mac. Installation and use process depends on your operating system. This info is taken from (Bellard 2016). Quicktime Player is natively installed on most of Mac computers. This tutorial focuses on Linux and Mac. Table of content 1. Introduction.......................................................................................................................................1 2. Linux.................................................................................................................................................1 2.1. FFmpeg......................................................................................................................................1 2.1.1. installation for Linux..........................................................................................................1 2.1.1.1. Add necessary components........................................................................................1 2.1.2. Screen recording with FFmpeg..........................................................................................2 2.1.2.1. List devices to know which one to record..................................................................2 2.1.2.2. Record screen and audio from your computer...........................................................3 2.2. Kazam........................................................................................................................................4
    [Show full text]
  • Forensic Identification of Unique Kali Systems Through the Use of File Hashes and Names
    Forensic Identification of Unique Kali Systems Through the Use of File Hashes and Names Troy Ward January 25, 2021 Troy Ward Table of Contents Introduction .................................................................................................................................................. 4 Kali Linux ....................................................................................................................................................... 4 Methodology ................................................................................................................................................. 4 Analysis ......................................................................................................................................................... 5 Unique Names ............................................................................................................................................... 6 Eth0.lease .................................................................................................................................................. 6 Font Config ................................................................................................................................................ 7 LightDM ..................................................................................................................................................... 8 System.Journal .........................................................................................................................................
    [Show full text]
  • Papermerge Documentation
    Papermerge Feb 29, 2020 Contents 1 Requirements 3 1.1 Python..................................................3 1.2 Imagemagick...............................................3 1.3 Poppler..................................................3 1.4 Tesseract.................................................4 1.5 Database.................................................4 2 Installation 5 2.1 OS Specific Packages..........................................5 2.1.1 1. Web App + Workers Machine................................5 2.1.1.1 Ubuntu Bionic 18.04 (LTS)..............................5 2.1.2 2. Web App Machine......................................6 2.1.2.1 Ubuntu Bionic 18.04 (LTS)..............................6 2.1.3 3. Worker Machine.......................................6 2.2 Manual Way...............................................6 2.2.1 Package Dependencies.....................................6 2.2.2 Web App............................................7 2.2.3 Worker.............................................9 2.2.4 Recurring Commands...................................... 10 2.3 Systemd................................................. 11 2.3.1 Package Dependencies..................................... 11 2.3.2 Web App............................................ 11 2.4 Docker.................................................. 13 2.5 Ansible (Semiautomated)........................................ 13 2.6 Jenkins + Ansible (Fully Automated Deployment)........................... 14 3 Languages Support 15 4 REST API 17 4.1 How It Works?.............................................
    [Show full text]
  • Design and Implementation of Generics for the .NET Common Language Runtime
    Design and Implementation of Generics for the .NET Common Language Runtime Andrew Kennedy Don Syme Microsoft Research, Cambridge, U.K. fakeÒÒ¸d×ÝÑeg@ÑicÖÓ×ÓfغcÓÑ Abstract cally through an interface definition language, or IDL) that is nec- essary for language interoperation. The Microsoft .NET Common Language Runtime provides a This paper describes the design and implementation of support shared type system, intermediate language and dynamic execution for parametric polymorphism in the CLR. In its initial release, the environment for the implementation and inter-operation of multiple CLR has no support for polymorphism, an omission shared by the source languages. In this paper we extend it with direct support for JVM. Of course, it is always possible to “compile away” polymor- parametric polymorphism (also known as generics), describing the phism by translation, as has been demonstrated in a number of ex- design through examples written in an extended version of the C# tensions to Java [14, 4, 6, 13, 2, 16] that require no change to the programming language, and explaining aspects of implementation JVM, and in compilers for polymorphic languages that target the by reference to a prototype extension to the runtime. JVM or CLR (MLj [3], Haskell, Eiffel, Mercury). However, such Our design is very expressive, supporting parameterized types, systems inevitably suffer drawbacks of some kind, whether through polymorphic static, instance and virtual methods, “F-bounded” source language restrictions (disallowing primitive type instanti- type parameters, instantiation at pointer and value types, polymor- ations to enable a simple erasure-based translation, as in GJ and phic recursion, and exact run-time types.
    [Show full text]
  • Mashup Architecture for Connecting Graphical Linux Applications Using a Software Bus Mohamed-Ikbel Boulabiar, Gilles Coppin, Franck Poirier
    Mashup Architecture for Connecting Graphical Linux Applications Using a Software Bus Mohamed-Ikbel Boulabiar, Gilles Coppin, Franck Poirier To cite this version: Mohamed-Ikbel Boulabiar, Gilles Coppin, Franck Poirier. Mashup Architecture for Connecting Graph- ical Linux Applications Using a Software Bus. Interacción’14, Sep 2014, Puerto de la Cruz. Tenerife, Spain. 10.1145/2662253.2662298. hal-01141934 HAL Id: hal-01141934 https://hal.archives-ouvertes.fr/hal-01141934 Submitted on 14 Apr 2015 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Mashup Architecture for Connecting Graphical Linux Applications Using a Software Bus Mohamed-Ikbel Gilles Coppin Franck Poirier Boulabiar Lab-STICC Lab-STICC Lab-STICC Telecom Bretagne, France University of Bretagne-Sud, Telecom Bretagne, France gilles.coppin France mohamed.boulabiar @telecom-bretagne.eu franck.poirier @telecom-bretagne.eu @univ-ubs.fr ABSTRACT functionalities and with different and redundant implemen- Although UNIX commands are simple, they can be com- tations that forced special users as designers to use a huge bined to accomplish complex tasks by piping the output of list of tools in order to accomplish a bigger task. In this one command, into another's input.
    [Show full text]
  • Arxiv:2007.15943V1 [Cs.SE] 31 Jul 2020
    MUZZ: Thread-aware Grey-box Fuzzing for Effective Bug Hunting in Multithreaded Programs Hongxu Chen§† Shengjian Guo‡ Yinxing Xue§∗ Yulei Sui¶ Cen Zhang† Yuekang Li† Haijun Wang# Yang Liu† †Nanyang Technological University ‡Baidu Security ¶University of Technology Sydney §University of Science and Technology of China #Ant Financial Services Group Abstract software performance. A typical computing paradigm of mul- tithreaded programs is to accept a set of inputs, distribute Grey-box fuzz testing has revealed thousands of vulner- computing jobs to threads, and orchestrate their progress ac- abilities in real-world software owing to its lightweight cordingly. Compared to sequential programs, however, multi- instrumentation, fast coverage feedback, and dynamic adjust- threaded programs are more prone to severe software faults. ing strategies. However, directly applying grey-box fuzzing On the one hand, the non-deterministic thread-interleavings to input-dependent multithreaded programs can be extremely give rise to concurrency-bugs like data-races, deadlocks, inefficient. In practice, multithreading-relevant bugs are usu- etc [32]. These bugs may cause the program to end up with ab- ally buried in the sophisticated program flows. Meanwhile, normal results or unexpected hangs. On the other hand, bugs existing grey-box fuzzing techniques do not stress thread- that appear under specific inputs and interleavings may lead interleavings that affect execution states in multithreaded pro- to concurrency-vulnerabilities [5, 30], resulting in memory grams. Therefore, mainstream grey-box fuzzers cannot ade- corruptions, information leakage, etc. quately test problematic segments in multithreaded software, although they might obtain high code coverage statistics. There exist a line of works on detecting bugs and vulner- To this end, we propose MUZZ, a new grey-box fuzzing abilities in multithreaded programs.
    [Show full text]
  • Modeling of Hardware and Software for Specifying Hardware Abstraction
    Modeling of Hardware and Software for specifying Hardware Abstraction Layers Yves Bernard, Cédric Gava, Cédrik Besseyre, Bertrand Crouzet, Laurent Marliere, Pierre Moreau, Samuel Rochet To cite this version: Yves Bernard, Cédric Gava, Cédrik Besseyre, Bertrand Crouzet, Laurent Marliere, et al.. Modeling of Hardware and Software for specifying Hardware Abstraction Layers. Embedded Real Time Software and Systems (ERTS2014), Feb 2014, Toulouse, France. hal-02272457 HAL Id: hal-02272457 https://hal.archives-ouvertes.fr/hal-02272457 Submitted on 27 Aug 2019 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Modeling of Hardware and Software for specifying Hardware Abstraction Layers Yves BERNARD1, Cédric GAVA2, Cédrik BESSEYRE1, Bertrand CROUZET1, Laurent MARLIERE1, Pierre MOREAU1, Samuel ROCHET2 (1) Airbus Operations SAS (2) Subcontractor for Airbus Operations SAS Abstract In this paper we describe a practical approach for modeling low level interfaces between software and hardware parts based on SysML operations. This method is intended to be applied for the development of drivers involved on what is classically called the “hardware abstraction layer” or the “basic software” which provide high level services for resources management on the top of a bare hardware platform.
    [Show full text]
  • Seed Selection for Successful Fuzzing
    Seed Selection for Successful Fuzzing Adrian Herrera Hendra Gunadi Shane Magrath ANU & DST ANU DST Australia Australia Australia Michael Norrish Mathias Payer Antony L. Hosking CSIRO’s Data61 & ANU EPFL ANU & CSIRO’s Data61 Australia Switzerland Australia ABSTRACT ACM Reference Format: Mutation-based greybox fuzzing—unquestionably the most widely- Adrian Herrera, Hendra Gunadi, Shane Magrath, Michael Norrish, Mathias Payer, and Antony L. Hosking. 2021. Seed Selection for Successful Fuzzing. used fuzzing technique—relies on a set of non-crashing seed inputs In Proceedings of the 30th ACM SIGSOFT International Symposium on Software (a corpus) to bootstrap the bug-finding process. When evaluating a Testing and Analysis (ISSTA ’21), July 11–17, 2021, Virtual, Denmark. ACM, fuzzer, common approaches for constructing this corpus include: New York, NY, USA, 14 pages. https://doi.org/10.1145/3460319.3464795 (i) using an empty file; (ii) using a single seed representative of the target’s input format; or (iii) collecting a large number of seeds (e.g., 1 INTRODUCTION by crawling the Internet). Little thought is given to how this seed Fuzzing is a dynamic analysis technique for finding bugs and vul- choice affects the fuzzing process, and there is no consensus on nerabilities in software, triggering crashes in a target program by which approach is best (or even if a best approach exists). subjecting it to a large number of (possibly malformed) inputs. To address this gap in knowledge, we systematically investigate Mutation-based fuzzing typically uses an initial set of valid seed and evaluate how seed selection affects a fuzzer’s ability to find bugs inputs from which to generate new seeds by random mutation.
    [Show full text]
  • Efficient Multi-Codec Support for OTT Services: HEVC/H.265 And/Or AV1?
    Efficient Multi-Codec Support for OTT Services: HEVC/H.265 and/or AV1? Christian Timmerer†,‡, Martin Smole‡, and Christopher Mueller‡ ‡Bitmovin Inc., †Alpen-Adria-Universität San Francisco, CA, USA and Klagenfurt, Austria, EU ‡{firstname.lastname}@bitmovin.com, †{firstname.lastname}@itec.aau.at Abstract – The success of HTTP adaptive streaming is un- multiple versions (e.g., different resolutions and bitrates) and disputed and technical standards begin to converge to com- each version is divided into predefined pieces of a few sec- mon formats reducing market fragmentation. However, other onds (typically 2-10s). A client first receives a manifest de- obstacles appear in form of multiple video codecs to be sup- scribing the available content on a server, and then, the client ported in the future, which calls for an efficient multi-codec requests pieces based on its context (e.g., observed available support for over-the-top services. In this paper, we review the bandwidth, buffer status, decoding capabilities). Thus, it is state of the art of HTTP adaptive streaming formats with re- able to adapt the media presentation in a dynamic, adaptive spect to new services and video codecs from a deployment way. perspective. Our findings reveal that multi-codec support is The existing different formats use slightly different ter- inevitable for a successful deployment of today's and future minology. Adopting DASH terminology, the versions are re- services and applications. ferred to as representations and pieces are called segments, which we will use henceforth. The major differences between INTRODUCTION these formats are shown in Table 1. We note a strong differ- entiation in the manifest format and it is expected that both Today's over-the-top (OTT) services account for more than MPEG's media presentation description (MPD) and HLS's 70 percent of the internet traffic and this number is expected playlist (m3u8) will coexist at least for some time.
    [Show full text]
  • Adding Self-Healing Capabilities to the Common Language Runtime
    Adding Self-healing capabilities to the Common Language Runtime Rean Griffith Gail Kaiser Columbia University Columbia University [email protected] [email protected] Abstract systems can leverage to maintain high system availability is to perform repairs in a degraded mode of operation[23, 10]. Self-healing systems require that repair mechanisms are Conceptually, a self-managing system is composed of available to resolve problems that arise while the system ex- four (4) key capabilities [12]; Monitoring to collect data ecutes. Managed execution environments such as the Com- about its execution and operating environment, performing mon Language Runtime (CLR) and Java Virtual Machine Analysis over the data collected from monitoring, Planning (JVM) provide a number of application services (applica- an appropriate course of action and Executing the plan. tion isolation, security sandboxing, garbage collection and Each of the four functions participating in the Monitor- structured exception handling) which are geared primar- Analyze-Plan-Execute (MAPE) loop consumes and pro- ily at making managed applications more robust. How- duces knowledgewhich is integral to the correct functioning ever, none of these services directly enables applications of the system. Over its execution lifetime the system builds to perform repairs or consistency checks of their compo- and refines a knowledge-base of its behavior and environ- nents. From a design and implementation standpoint, the ment. Information in the knowledge-base could include preferred way to enable repair in a self-healing system is patterns of resource utilization and a “scorecard” tracking to use an externalized repair/adaptation architecture rather the success of applying specific repair actions to detected or than hardwiring adaptation logic inside the system where it predicted problems.
    [Show full text]