DOCSLIB.ORG

Common Coupling As a Measure of Reuse Effort in Kernel-Based Software with Case Studies on the Creation of Mklinux and Darwin

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Common Coupling As a Measure of Reuse Effort in Kernel-Based Software with Case Studies on the Creation of Mklinux and Darwin IUScholarWorks at Indiana University South Bend Common Coupling as a Measure of Reuse Effort in Kernel-Based Software with Case Studies on the Creation of MkLinux and Darwin Yu, Liguo To cite this article: Yu, Liguo. “Common Coupling as a Measure of Reuse Effort in Kernel-Based Software with Case Studies on the Creation of MkLinux and Darwin.” Journal of the Brazilian Computer Society14, vol. 14, no. 1, Feb. 2008, pp. 45–55. This document has been made available through IUScholarWorks repository, a service of the Indiana University Libraries. Copyrights on documents in IUScholarWorks are held by their respective rights holder(s). Contact [email protected] for more information. Common Coupling as a Measure of Reuse Effort in Kernel-Based Software with Case Studies on the Creation of MkLinux and Darwin Liguo Yu Department of Informatics Computer and Information Sciences Department Indiana University South Bend South Bend, IN 46634, USA. Fax: 1-574-520-5589 E-mail: [email protected] The initial version of this paper appers in the 19th International Conference on Software Engineering and Knowledge Engineering. Abstract software components, which required less effort in order to be reused to produce Darwin. An obstacle to software reuse is the large number of major modifications that frequently have to be made Keywords: Reuse, common coupling, kernel-based software, as a consequence of dependencies within the reused MkLinux, Darwin software components. In this paper, common coupling is categorized and used as a measure of the dependencies 1. INTRODUCTION between software components. We compared common Software reuse has become a topic of interest within coupling in three operating systems, Linux, FreeBSD, the software community because of its potential and Mach, and related it to the reuse effort of these benefits. These include increased productivity and systems. The measure is evaluated by studying the quality, and decreased cost and time-to-market. creation of two operating systems, MkLinux which is Obviously the biggest savings are to be found in large- based on the reuse of Linux and Mach, and Darwin scale reuse, that is, the reuse of a large portion of an which is based on the reuse of FreeBSD and Mach. We existing software product. A considerable amount of conclude that the way that common coupling is research has been undertaken in this area [1, 2, 3]. implemented in Linux kernel induces large dependencies One problem with software reuse is that large between software components, which required more software components may be dependent on other effort in order to be reused to produce MkLinux, while components. On the one hand, suppose that the the common coupling implemented in the Mach and components of a software product are classes that FreeBSD kernels induces few dependencies between communicate exclusively by message passing. The Common Coupling as a Measure of Reuse Effort in Kernel-Based Liguo Yu Software with Case Studies on the Creation of MkLinux and Darwin dependency between the components is low, and it should and Mach, and Darwin is produced through the reuse of be possible to reuse one component in a new software FreeBSD and Mach. However, MkLinux and Darwin product with little difficulty. But if a software product have different fates. MkLinux is active for only several consists of components, all of which reference a large years (1996 to 2001) and the development is dormant number of global variables, it may be impossible to reuse now. In contrast, Darwin is considered a successfully any one component in a new product without first totally project and has continually being developed and used redesigning and reimplementing that component, thereby since 1998. In this paper, we use common coupling as a all but defeating the purpose of reuse. measure to study the reuse effort in the creation of the two operating systems. Many software products, including operating systems and database management systems, are kernel-based. The remainder of the paper is divided into six That is, each implementation consists of required kernel sections. Section 2 discusses component dependencies components, together with specific optional architecture- and reuse effort. In Section 3, we review the specific or hardware-specific non-kernel components. The categorization of common coupling and discuss its word kernel is overloaded. It can refer to a nucleus that relation to reuse effort. We introduce additional can execute certain instructions [4, 5], or to a set of terminology in Section 4. Section 5 describes MkLinux, modules that are included in every installation. In this Darwin, and other open-source operating systems. Section paper, we use “kernel” in the latter sense. 6 contains the results of our study of open-source operating systems. The conclusions are in Section 7. Coupling is a measure of the degree of interaction between two software components. It reflects the modifiability and the maintainability of a software 2. SOFTWARE DEPENDENCIES AND REUSE product [6]. There are many different categorizations of EFFORT coupling, all of which include common (global) Coupling is a measure of the degree of dependency coupling (two software components are common between two software components (classes, modules, coupled if they reference the same global variable). packages, or the like). A good software system should Certain types of coupling, especially common coupling, have high cohesion within each component and weak are considered to present risks for software development coupling between components. Coupling between and, in particular, for maintenance [7]. Common components strengthens the dependency of one coupling can also be used to measure the dependencies component on others and increases the probability that between software components [8]. To reuse a kernel changes in one component may affect other components. component in another software product, it is important There are several different coupling categorizations [6, that the kernel component should have minimal 9], all of which include common coupling. Common dependency on other components. Accordingly, it is coupling is considered to be a strong form of coupling, important that the kernel components have as little that is, it induces strong dependencies between software common coupling as possible. components, making software components difficult to In a previous study, Yu et al. [8] defined a new understand, maintain, and reuse [7]. categorization of common coupling within kernel-based If a software component has strong dependencies (such software, and used it to measure the maintenance effort as common coupling) on other components, it requires of kernel-based software. In this paper, we extend the more effort to be adapted to a new environment. Common categorization and use it to evaluate reuse effort in coupling makes a software component difficult to reuse for kernel-based software. Reuse and maintenance are two reasons. First, suppose that we wish to reuse different in many ways. For example, reuse is almost component C0, and that C0 is common coupled to n always optional, and often just one component or a few components C1, C2, … Cn. One alternative would be to related components are reused. In contrast, maintenance incorporate and reuse not just C0 but also components C1 is usually required, especially corrective maintenance, through Cn as well. However, this would result in and maintenance has to be performed on a software unnecessary reuse and make the resulting product hard to product as a whole (hence the need for regression comprehend. A second alternative is to reuse component testing). On the other hand, reuse and maintenance have C0 on its own, that is, without components C1 through Cn. at least one feature in common: Both are adversely In order to do this, we would need to make major affected by common coupling. modifications to C0. In fact, these modifications might well MkLinux and Darwin are the outcomes of Apple be so drastic that it would be cheaper and quicker to design Computer’s endeavor to create new operating systems and implement a new version of C0 from scratch, rather based on the reuse of existing operating systems, in than reuse the existing version. Therefore, it requires more which MkLinux is produced through the reuse of Linux effort to reuse a component with strong coupling, like common coupling. 46 Common Coupling as a Measure of Reuse Effort in Kernel-Based Liguo Yu Software with Case Studies on the Creation of MkLinux and Darwin The kernel is the common part of a kernel-based We consider two types of reuse. We refer to the software product. It is the most frequently reused reuse of one or more independent kernel components as component; reuse of kernel-based software usually kernel-component reuse and the reuse of all of the kernel consists of reusing all or most of the kernel, together as entire-kernel reuse. When we wish to refer to either with certain other non-kernel components. Therefore, kernel-component reuse or entire-kernel reuse, we use the effort involved in reusing the kernel reflects the the umbrella term kernel reuse. reuse effort of a kernel-based software product. Dependencies induced by common coupling affect Common coupling within a kernel-based product may the reuse effort; in general, more effort is needed to increase the dependency of the kernel on non-kernel reuse a component with a large number of global components and, therefore, it would require more effort variables. However, reuse effort is also affected by the to reuse the kernel or the software product as a whole. category into which each global variable falls. 3. COMMON COUPLING AND SOFTWARE A category-1 global variable is not used in a kernel component, so definitions of the global REUSE EFFORT variable in other components (kernel or non-kernel) Common coupling induces dependencies between cannot affect kernel components. All kernel software components.
Load more

Recommended publications
  • Chapter 1. Origins of Mac OS X
    1 Chapter 1. Origins of Mac OS X "Most ideas come from previous ideas." Alan Curtis Kay The Mac OS X operating system represents a rather successful coming together of paradigms, ideologies, and technologies that have often resisted each other in the past. A good example is the cordial relationship that exists between the command-line and graphical interfaces in Mac OS X. The system is a result of the trials and tribulations of Apple and NeXT, as well as their user and developer communities. Mac OS X exemplifies how a capable system can result from the direct or indirect efforts of corporations, academic and research communities, the Open Source and Free Software movements, and, of course, individuals. Apple has been around since 1976, and many accounts of its history have been told. If the story of Apple as a company is fascinating, so is the technical history of Apple's operating systems. In this chapter,[1] we will trace the history of Mac OS X, discussing several technologies whose confluence eventually led to the modern-day Apple operating system. [1] This book's accompanying web site (www.osxbook.com) provides a more detailed technical history of all of Apple's operating systems. 1 2 2 1 1.1. Apple's Quest for the[2] Operating System [2] Whereas the word "the" is used here to designate prominence and desirability, it is an interesting coincidence that "THE" was the name of a multiprogramming system described by Edsger W. Dijkstra in a 1968 paper. It was March 1988. The Macintosh had been around for four years.
    [Show full text]
  • Kernel Architectures
    A short history of kernels n Early kernel: a library of device drivers, support for threads (QNX) Operating System Kernels n Monolithic kernels: Unix, VMS, OS 360… n Unstructured but fast… n Over time, became very large Ken Birman n Eventually, DLLs helped on size n Pure microkernels: Mach, Amoeba, Chorus… (borrowing some content from n OS as a kind of application Peter Sirokman) n Impure microkernels: Modern Windows OS n Microkernel optimized to support a single OS n VMM support for Unix on Windows and vice versa The great m-kernel debate Summary of First Paper n How big does it need to be? n The Performance of µ-Kernel-Based Systems (Hartig et al. 16th SOSP, Oct 1997) n With a m-kernel protection-boundary crossing forces us to n Evaluates the L4 microkernel as a basis for a full operating system n Change memory -map n Ports Linux to run on top of L4 and compares n Flush TLB (unless tagged) performance to native Linux and Linux running on n With a macro-kernel we lose structural the Mach microkernel protection benefits and fault-containment n Explores the extensibility of the L4 microkernel n Debate raged during early 1980’s Summary of Second Paper In perspective? n The Flux OSKit: A Substrate for Kernel and n L4 seeks to validate idea that a m-kernel Language Research (Ford et al. 16th SOSP, can support a full OS without terrible 1997) cost penalty n Describes a set of OS components designed to be used to build custom operating systems n Opened the door to architectures like the n Includes existing code simply using “glue code” Windows
    [Show full text]
  • Computer Architectures an Overview
    Computer Architectures An Overview PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 25 Feb 2012 22:35:32 UTC Contents Articles Microarchitecture 1 x86 7 PowerPC 23 IBM POWER 33 MIPS architecture 39 SPARC 57 ARM architecture 65 DEC Alpha 80 AlphaStation 92 AlphaServer 95 Very long instruction word 103 Instruction-level parallelism 107 Explicitly parallel instruction computing 108 References Article Sources and Contributors 111 Image Sources, Licenses and Contributors 113 Article Licenses License 114 Microarchitecture 1 Microarchitecture In computer engineering, microarchitecture (sometimes abbreviated to µarch or uarch), also called computer organization, is the way a given instruction set architecture (ISA) is implemented on a processor. A given ISA may be implemented with different microarchitectures.[1] Implementations might vary due to different goals of a given design or due to shifts in technology.[2] Computer architecture is the combination of microarchitecture and instruction set design. Relation to instruction set architecture The ISA is roughly the same as the programming model of a processor as seen by an assembly language programmer or compiler writer. The ISA includes the execution model, processor registers, address and data formats among other things. The Intel Core microarchitecture microarchitecture includes the constituent parts of the processor and how these interconnect and interoperate to implement the ISA. The microarchitecture of a machine is usually represented as (more or less detailed) diagrams that describe the interconnections of the various microarchitectural elements of the machine, which may be everything from single gates and registers, to complete arithmetic logic units (ALU)s and even larger elements.
    [Show full text]
  • Kernel-Based Systems
    The Performance of µ-Kernel-Based Systems Liedtke et al. presented by: Ryan O’Connor <[email protected]> October 7th, 2009 Liedtke et al.presented by: Ryan O’Connor <[email protected]> The Performance of µ-Kernel-Based Systems Motivation By this time (1997) the OS research community had virtually abandoned research on pure µ-kernels. due primarily to the poor performance of first-generation µ-kernels Many researchers believe that µ-kernel abstraction layer is either too low or too high too low: research should focus on extensible-kernels, allowing users to safely add new functionality to a monolithic kernel too high: kernels should export an interface resembling a hardware architecture Claim: pure µ-kernels are not fundamentally flawed, they just haven’t been done right yet Liedtke et al.presented by: Ryan O’Connor <[email protected]> The Performance of µ-Kernel-Based Systems Contributions L4 and L4Linux the penalty for using a pure µ-kernel can be kept between 5% and 10% µ-kernel abstractions are efficient enough to motivate their use in user applications Liedtke et al.presented by: Ryan O’Connor <[email protected]> The Performance of µ-Kernel-Based Systems L4 L4 exports a pure µ-kernel interface (threads, address spaces, and IPC). In addition it supports: user-level paging, and recursive construction of address spaces translation of hardware interrupts to IPC messages fast context switches on small address-spaces using Pentium segmentation trick Liedtke et al.presented by: Ryan O’Connor <[email protected]> The Performance of µ-Kernel-Based Systems L4Linux L4Linux is a Linux Single Server, an L4 process that provides a unix ’personality’ for user applications.
    [Show full text]
  • Popcorn Project: Starting with Popcorn OS
    Popcorn Project: Starting with Popcorn OS Antonio Barbalace [email protected] Systems Software Research Group at Virginia Tech http://ssrg.ece.vt.edu VTLUUG meeting , May 2 nd 2013 Patches 14 th Dec 2012 • Popcorn Hacking Guide – Generic modifications (all archs) • linux-3.2.14-popcorn-build.patch • linux-3.2.14-popcorn-syscall.patch • linux-3.2.14-popcorn-generic.patch – Architecture dependent in arch/x86 • linux-3.2.14-popcorn-x86-build.patch • linux-3.2.14-popcorn-x86-syscall.patch • linux-3.2.14-popcorn-x86-generic.patch • linux-3.2.14-popcorn-x86-apic.patch • linux-3.2.14-popcorn-x86-boot.patch • linux-3.2.14-popcorn-x86-vty.patch – Drivers modifications (all archs) in drivers/ • linux-3.2.14-popcorn-drivers-vty.patch • linux-3.2.14-popcorn-drivers-acpi.patch • linux-3.2.14-popcorn-drivers-gpu.patch • linux-3.2.14-popcorn-drivers-pci.patch • Goal – Release a first usable version of the project (alternative to virtual machines) – Document the project – Attract contributors and enthusiasts – Separate the architecture dependent code (initial porting guide) 2 Patches 25 th Mar 2013 • Goal – Release a new usable version of the project (replicated-kernel) – Add new components • Inter-Kernel Messaging layer • Remote process creation and migration • Other improvements and fixes 3 GIT Repositories • Hosted on TO BE ANNOUNCED – Publicly browseable, direct r/w access is protected (ssh key required) • Kernel code – TO BE ANNOUNCED – many different branches • davek – process/thread remote creation, migration • net_msg_integration – fast software network switch • shmem_tuntap – software network switch using TUN/TAP • bshelton_messaging – inter-kernel messaging layer • andy_fd_aware – NUMA aware scheduling • andy_load_balance – again, NUMA aware scheduling • mklinux-readonly – one page table per NUMA-node • etc.
    [Show full text]
  • Applications/Utilities
    [ Team LiB ] • Table of Contents • Index • Reviews • Reader Reviews • Errata • Academic Mac OS X Panther for Unix Geeks By Brian Jepson, Ernest E. Rothman Publisher: O'Reilly Pub Date: February 2004 ISBN: 0-596-00607-1 Pages: 240 If you find yourself disoriented by the new Mac environment, Mac OS X Panther for Unix Geeks will get you acclimated quickly to the foreign new areas of a familiar Unix landscape. The new edition of this book is your guide to figuring out the BSD Unix system and Panther-specific components that you may find challenging. The book includes a quick manpage-style reference to the "Missing Manual Pages" --commands that come with Mac OS X Panther, although there are no manpages. [ Team LiB ] [ Team LiB ] • Table of Contents • Index • Reviews • Reader Reviews • Errata • Academic Mac OS X Panther for Unix Geeks By Brian Jepson, Ernest E. Rothman Publisher: O'Reilly Pub Date: February 2004 ISBN: 0-596-00607-1 Pages: 240 Copyright Preface Audience for This Book Organization of This Book Xcode Tools Where to Go for More Information Conventions Used in This Book Comments and Questions Acknowledgments from the Previous Edition Acknowledgments from Brian Jepson Acknowledgments from Ernest E. Rothman Part I: Getting Around Chapter 1. Inside the Terminal Section 1.1. Mac OS X Shells Section 1.2. The Terminal and xterm Compared Section 1.3. Using the Terminal Section 1.4. Customizing the Terminal Section 1.5. The Services Menu Section 1.6. Alternative Terminal Applications Section 1.7. The open Command Chapter 2. Startup Section 2.1.
    [Show full text]
  • 101 Ways to Save Apple by James Daly
    http://www.wired.com/wired/archive/5.06/apple_pr.html 101 Ways to Save Apple By James Daly An assessment of what can be done to fix a once-great company. Dear Apple, In the movie Independence Day, a PowerBook saves the earth from destruction. Now it's time to return the favor. Unfortunately, even devoted Mac addicts must admit that you look a little beleaguered these days: a confusing product line, little inspiration from the top, software developers fleeing. But who wants to live in a world without you? Not us. So we surveyed a cross section of hardcore Mac fans and came up with 101 ways to get you back on the path to salvation. We chose not to resort to time travel or regurgitate the same old shoulda/coulda/wouldas (you shoulda licensed your OS in 1987, for instance, or coulda upped your price/performance in 1993). We don't believe Apple is rotten to the core. Chrysler nearly went under in the late 1970s and came back to lead its industry. Here's a fresh assessment of what can be done to fix your once-great company using the material at hand. Don't wait for a miracle. You have the power to save the world - and yourself. Edited by James Daly 1. Admit it. You're out of the hardware game. Outsource your hardware production, or scrap it entirely, to compete more directly with Microsoft without the liability of manufacturing boxes. 2. License the Apple name/technology to appliance manufacturers and build GUIs for every possible device - from washing machines to telephones to WebTV.
    [Show full text]
  • Contents of Lecture 8 on UNIX History
    Contents of Lecture 8 on UNIX History Before UNIX Origin of UNIX Commerical wars and other threats Linux Game over. UNIX won. Continued work by the original UNIX team: Plan 9 and Inferno Microkernels vs Monolithic kernels and other issues. Jonas Skeppstedt ([email protected]) Lecture 8 2014 1 / 67 CTSS The Compatible Time-Sharing System was designed at MIT in the early 1960s. Supported up to 32 simultanously logged in users: proof of the time-sharing idea. Ran on IBM 7090 with 32K 36 bit words, of which the monitor used 5K. User programs were swapped in from a magnetic drum (disk). Multilevel feedback scheduling queue. Higher priorities have shorter time quantum Initial priority (quantum) reflects size of the executable file so it can be swapped in and run. CTSS was extremely successful and used as late as 1972: basis for MULTICS. Jonas Skeppstedt ([email protected]) Lecture 8 2014 2 / 67 MULTICS Multiplexed Information and Computing Ser vice designed by MIT, AT&T, and GE. AT&T and GE provided telephone and electricity ser vices as utilities. GE also produced computers, eg the GE-645 used in MULTICS development. Why not do the same with computing power? The goal was one computer for 100,000s users in Boston (on hardware equivalent to about 386 or 486). Designed as an extension to CTSS with virtual memory and sophisticated protection (more levels than UNIX user vs superuser). MULTICS was written in PL/1 and consisted of about 300,000 lines. Jonas Skeppstedt ([email protected]) Lecture 8 2014 3 / 67 End of MULTICS Lots of people were very enthusiastic about MULTICS, including the newly graduated Ken Thompson from Berkeley.
    [Show full text]
  • Microkernels: Mach and L4
    Microkernels: Mach and L4 Presented by Jason Wu With content borrowed from Dan Williams (2009) and Hakim Weatherspoon (2008) Outline • Introduction to Kernels • 1st Generation Microkernels – Mach • 2nd Generation Microkernels – L4 • Conclusions Introduction to Kernels • Different Types of Kernel Designs – Monolithic kernel – Microkernel – Hybrid Kernel – Exokernel – Virtual Machines? Monolithic Kernels • All OS services operate in kernel space • Good performance • Disadvantages – Dependencies between system component – Complex & huge (millions(!) of lines of code) – Larger size makes it hard to maintain • E.g. Multics, Unix, BSD, Linux Microkernels • Minimalist approach – IPC, virtual memory, thread scheduling • Put the rest into user space – Device drivers, networking, file system, user interface • More stable with less services in kernel space • Disadvantages – Lots of system calls and context switches • E.g. Mach, L4, AmigaOS, Minix, K42 Monolithic Kernels VS Microkernels Hybrid Kernels • Combine the best of both worlds – Speed and simple design of a monolithic kernel – Modularity and stability of a microkernel • Still similar to a monolithic kernel – Disadvantages still apply here • E.g. Windows NT, NetWare, BeOS Exokernels • Follows end-to-end principle – Extremely minimal – Fewest hardware abstractions as possible – Just allocates physical resources to apps • Disadvantages – More work for application developers • E.g. Nemesis, ExOS • Next Thursday! The Microkernel Debate • How big should it be? • Big debate during the 1980’s Summary:
    [Show full text]
  • The Performance of Μ-Kernel-Based Systems
    16th ACM Symposium on Operating Systems Principles (SOSP ’97), October 5–8, 1997, Saint-Malo, France The Performance of µ-Kernel-Based Systems Hermann Hartig¨ Michael Hohmuth Jochen Liedtke Sebastian Schonber¨ g Jean Wolter Dresden University of Technology IBM T. J. Watson Research Center Department of Computer Science 30 Saw Mill River Road D-01062 Dresden, Germany Hawthorne, NY 10532, USA email: [email protected] email: [email protected] based on pure µ-kernels, i. e. kernels that provide only ad- dress spaces, threads and IPC, or an equivalent set of primi- tives. This trend is due primarily to the poor performance ex- Abstract hibited by such systems constructed in the 1980’s and early 1990’s. This reputation has not changed even with the advent First-generation µ-kernels have a reputation for being too of faster µ-kernels; perhaps because these µ-kernel have for slow and lacking sufficient flexibility. To determine whether the most part only been evaluated using microbenchmarks. L4, a lean second-generation µ-kernel, has overcome these limitations, we have repeated several earlier experiments and Many people in the OS research community have adopted conducted some novel ones. Moreover, we ported the Linux the hypothesis that the layer of abstraction provided by pure operating system to run on top of the L4 µ-kernel and com- µ-kernels is either too low or too high. The “too low” fac- pared the resulting system with both Linux running native, tion concentrated on the extensible-kernel idea. Mechanisms and MkLinux, a Linux version that executes on top of a first- were introduced to add functionality to kernels and their ad- generation Mach-derived µ-kernel.
    [Show full text]
  • The Linux Kernel: Configuring the Kernel Part 22
    The Linux Kernel: Configuring the Kernel Part 22 In this article, we will continue to configure the kernel hacks and then we will configure the whole security system. The next feature to configure is needed by Alpha and s390 processor (Force weak per­cpu definitions). This feature offers a fix for an addressing issue commonly seen in such processors. Other processors do not need this feature enabled. Kernel dumps can be tested with this special debugging tool (Linux Kernel Dump Test Tool Module). This software will allow a kernel developer to trigger a fake error that will cause a kernel dump. The kernel developers can then ensure that the dumps complete successfully. The kernel offers some different error injection modules that allow kernel developers to test the notifiers (CPU notifier error injection module), (PM notifier error injection module), and (Memory hotplug notifier error injection module). A notifier informs the system that the hardware is present, which is important for hotplugging. These error injection modules trigger an error in this notification system so developers can test the notification system's error handling abilities. The "Fault­injection framework" driver offers various tools for testing fault­handling. The "Latency measuring infrastructure" driver provides the LatencyTOP tool used to find the userspace object that is blocking/interfering with a kernel execution/task. Next, we have a sub­menu titled "Tracers" that contains a list of various tracers. A tracer is a piece of code that watches various kernel functions. Every time a particular function starts, a tracer will be called to watch the function.
    [Show full text]
  • Application Signature: a New Way to Predict Application Performance Rajat Kumar Todi Iowa State University
    Iowa State University Capstones, Theses and Retrospective Theses and Dissertations Dissertations 2003 Application Signature: a new way to predict application performance Rajat Kumar Todi Iowa State University Follow this and additional works at: https://lib.dr.iastate.edu/rtd Part of the Computer Sciences Commons Recommended Citation Todi, Rajat Kumar, "Application Signature: a new way to predict application performance " (2003). Retrospective Theses and Dissertations. 1913. https://lib.dr.iastate.edu/rtd/1913 This Dissertation is brought to you for free and open access by the Iowa State University Capstones, Theses and Dissertations at Iowa State University Digital Repository. It has been accepted for inclusion in Retrospective Theses and Dissertations by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Application Signature: A new way to predict application performance by Rajat Kumar Todi A dissertation submitted to the graduate faculty in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY Major: Computer Science Program of Study Committee: John Gustafson, Co-major Professor Gurpur Prabhu, Co-major Professor Don Heller Srinivas Aluru Doug Jacobson Iowa State University Ames, Iowa 2003 Copyright © Rajat Kumar Todi, 2003. All rights reserved. UMI Number: 3279645 INFORMATION TO USERS The quality of this reproduction is dependent upon the quality of the copy submitted. Broken or indistinct print, colored or poor quality illustrations and photographs, print bleed-through, substandard margins, and improper alignment can adversely affect reproduction. In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted.
    [Show full text]