DOCSLIB.ORG

Optimising Java Programs Through Basic Block Dynamic Compilation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Optimising Java Programs Through Basic Block Dynamic Compilation OPTIMISING JAVA PROGRAMS THROUGH BASIC BLOCK DYNAMIC COMPILATION A modified version of a thesis submitted to the University of Manchester for the degree of Doctor of Philosophy in the Faculty of Science and Engineering September 2002 By Ian A. Rogers Department of Computer Science Contents Abstract 11 Declaration 12 Copyright 13 The Author 14 Acknowledgements 15 Alterations 16 1 Introduction 17 1.1 The problem . 17 1.2 The solution . 18 1.3 Contributions . 21 1.4 Outline . 22 2 The Java Virtual Machine 23 2.1 What is Java? . 23 2.2 Objects . 25 2.3 Class file . 28 2.4 Class library and native methods . 30 2.5 Linking and loading . 31 2.6 Exceptions . 32 2.7 Interpreter JVMs . 34 2.8 Hardware JVMs . 37 2.9 Just-In-Time and dynamic compilation JVMs . 38 2.9.1 Method inlining . 39 2 2.10 HotSpot . 41 2.11 Summary . 43 3 Dynamic Binary Translation 45 3.1 Overview . 45 3.2 Above operating system dynamic binary translators . 49 3.2.1 FX!32 . 49 3.2.2 Dynamo . 51 3.2.3 UQDBT . 52 3.2.4 DAISY . 54 3.3 Between operating system dynamic binary translators . 54 3.3.1 VEST and mx . 55 3.3.2 Macintosh application environment . 55 3.3.3 Wabi . 56 3.3.4 VMWare . 56 3.4 Below operating system dynamic binary translators . 57 3.4.1 Transmeta . 57 3.5 Other directions . 58 3.6 Summary . 60 4 Dynamite 61 4.1 The Dynamite fuse module . 61 4.2 The Dynamite front-end module . 62 4.2.1 Building Dynamite’s intermediate representation . 62 4.2.2 Substitute calls . 63 4.3 The Dynamite kernel module . 63 4.3.1 Control . 63 4.3.2 Basic block cache . 64 4.3.3 Basic block compatibility . 64 4.3.4 Group blocks . 65 4.3.5 Dead code elimination . 65 4.3.6 Constant propagation . 65 4.3.7 Value-specific optimisation . 65 4.3.8 Code duplication . 66 4.4 Back-end . 66 4.4.1 Instruction scheduling . 66 3 4.4.2 Idiom recognition . 68 4.4.3 Code generation . 68 4.5 Summary . 68 5 Dynamite JVM 70 5.1 Instruction decoding . 70 5.1.1 Expression stack . 71 5.1.2 Control-of-flow bytecodes . 73 5.2 Exceptions . 75 5.3 Object layout . 77 5.4 Class loader . 79 5.4.1 Boot strapping . 79 5.4.2 New . 79 5.4.3 Checkcast and instanceof . 80 5.5 JNI . 81 5.6 Threading . 81 5.7 Related work . 82 5.8 Summary . 84 6 Inter-Procedure Optimisation 85 6.1 The method inlining problem . 85 6.2 Sliding register-window scheme . 87 6.3 Fixed register-window scheme . 87 6.4 Choice of register-window scheme . 91 6.4.1 Introduction of benchmarks . 91 6.4.2 Number of fix-up blocks for fixed register-window scheme . 92 6.4.3 Number of retranslations for sliding register-window scheme 96 6.4.4 Coverage of fixed register scheme . 99 6.4.5 Conclusion . 100 6.5 Summary . 101 7 Recursion 104 7.1 Lazy recursion detection . 104 7.1.1 Single recursion . 107 7.1.2 Direct mutual-recursion . 108 7.1.3 Indirect mutual-recursion . 110 4 7.2 Fixing the call stack . 111 7.2.1 Immediate stack fix-up technique . 111 7.2.2 Delayed stack fix-up technique . 112 7.2.3 Chosen scheme . 114 7.2.4 Example stack fix-up . 114 7.3 Performance . 115 7.3.1 Cost of recursion . 115 7.3.2 Cost of stack fix-up . 119 7.3.3 Performance comparison . 120 7.4 Summary . 125 8 Overall System Performance 126 8.1 Break down of JVM performance . 127 8.2 Translation saving . 129 8.3 Performance of translated code . 130 8.3.1 Externally measured performance . 130 8.3.2 Internally measured performance . 131 8.3.3 Analysis . 133 8.4 Translation performance . 135 8.5 Back-end performance . 139 8.6 Summary . 144 9 Summary and Conclusions 145 9.1 Summary . 145 9.1.1 Background . 145 9.1.2 Design . 145 9.1.3 Experiments . 146 9.2 Conclusions . 147 9.3 Future work . 148 9.3.1 Threading . 149 9.3.2 Garbage collection . 149 9.3.3 Exception handling . 150 9.3.4 Class library . 151 9.3.5 Memory usage . 152 9.3.6 Latency . 153 9.3.7 Performance . 154 5 9.4 Final remark . 154 A feJAVA Dynamite JVM Front-End 155 B Result Data 157 B.1 Number of fix-up blocks for fixed register-window scheme . 157 B.2 Number of retranslations for sliding register-window scheme . 157 B.3 Input to Takeuchi function . 160 Bibliography 162 6 List of Tables 3.1 Translation environments . 48 6.1 Benchmark translation and execution bytecode counts . 93 6.2 Percentage of method call bytecodes translated and executed in fixed register-window scheme . 95 6.3 Fixed register-window copying overhead per virtual call . 96 6.4 Overall sliding register-window statistics . 96 7.1 Descriptor abbreviation descriptions . 115 7.2 Recursive instruction counts . 117 7.3 Recursive instructions as a percentage of their base instruction . 117 7.4 Recursive bytecodes as a percentage of the total instruction mix . 117 7.5 The total size of frames saved and loaded from the memory stack by recursive invoke bytecodes . 118 7.6 The average size of frames saved to the memory stack by recursive invoke bytecodes . 118 7.7 Stack fix-up cost . 119 8.1 Number of translated bytes of a JIT compiler and the Dynamite JVM . 129 8.2 Reduction in translated bytes by basic block compilation ..
Load more

Recommended publications
  • The Architecture of Decentvm
    The Architecture of the DecentVM Towards a Decentralized Virtual Machine for Many-Core Computing Annette Bieniusa Johannes Eickhold Thomas Fuhrmann University of Freiburg, Germany Technische Universitat¨ Munchen,¨ Germany [email protected] fjeick,[email protected] Abstract We have accomplished these goals by combining an off-line Fully decentralized systems avoid bottlenecks and single points transcoder with a virtual machine that executes modified bytecode. of failure. Thus, they can provide excellent scalability and very The transcoder performs the verification and statically links the robust operation. The DecentVM is a fully decentralized, distributed required classes of an application or library. Thereby, the resulting virtual machine. Its simplified instruction set allows for a small binary – a so-called blob – is significantly smaller than the original VM code footprint. Its partitioned global address space (PGAS) class files, and its execution requires a significantly less complex memory model helps to easily create a single system image (SSI) virtual machine. Both these effects result in the low memory across many processors and processor cores. Originally, the VM was footprint of DecentVM. designed for networks of embedded 8-bit processors. Meanwhile, All libraries that are required by an application are identified via it also aims at clusters of many core processors. This paper gives a cryptographic hashes. Thus, an application’s code can be deployed brief overview of the DecentVM architecture. as if it was a statically linked executable. The software vendor can thus test the executable as it runs on the customer site without Categories and Subject Descriptors C.1.4 [Processor Architec- interference from different library versions.
    [Show full text]
  • SJC – Small Java Compiler
    SJC – Small Java Compiler User Manual Stefan Frenz Translation: Jonathan Brase original version: 2011/06/08 latest document update: 2011/08/24 Compiler Version: 182 Java is a registered trademark of Oracle/Sun Table of Contents 1 Quick introduction.............................................................................................................................4 1.1 Windows...........................................................................................................................................4 1.2 Linux.................................................................................................................................................5 1.3 JVM Environment.............................................................................................................................5 1.4 QEmu................................................................................................................................................5 2 Hello World.......................................................................................................................................6 2.1 Source Code......................................................................................................................................6 2.2 Compilation and Emulation...............................................................................................................8 2.3 Details...............................................................................................................................................9
    [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]
  • Dynamically Loaded Classes As Shared Libraries: an Approach to Improving Virtual Machine Scalability
    Dynamically Loaded Classes as Shared Libraries: an Approach to Improving Virtual Machine Scalability Bernard Wong Grzegorz Czajkowski Laurent Daynès University of Waterloo Sun Microsystems Laboratories 200 University Avenue W. 2600 Casey Avenue Waterloo, Ontario N2L 3G1, Canada Mountain View, CA 94043, USA [email protected] {grzegorz.czajkowski, laurent.daynes}@sun.com Abstract machines sold today have sufficient amount of memory to hold a few instances of the Java virtual machine (JVMTM) Sharing selected data structures among virtual [2]. However, on servers hosting many applications, it is machines of a safe language can improve resource common to have many instances of the JVM running utilization of each participating run-time system. The simultaneously, often for lengthy periods of time. challenge is to determine what to share and how to share Aggregate memory requirement can therefore be large, it in order to decrease start-up time and lower memory and meeting it by adding more memory is not always an footprint without compromising the robustness of the option. In these settings, overall memory footprint must be system. Furthermore, the engineering effort required to kept to a minimum. For personal computer users, the main implement the system must not be prohibitive. This paper irritation is due to long start-up time, as they expect good demonstrates an approach that addresses these concerns TM responsiveness from interactive applications, which in in the context of the Java virtual machine. Our system contrast is of little importance in enterprise computing. transforms packages into shared libraries containing C/C++ programs typically do not suffer from excessive classes in a format matching the internal representation memory footprint or lengthy start-up time.
    [Show full text]
  • Java (Programming Langua a (Programming Language)
    Java (programming language) From Wikipedia, the free encyclopedialopedia "Java language" redirects here. For the natural language from the Indonesian island of Java, see Javanese language. Not to be confused with JavaScript. Java multi-paradigm: object-oriented, structured, imperative, Paradigm(s) functional, generic, reflective, concurrent James Gosling and Designed by Sun Microsystems Developer Oracle Corporation Appeared in 1995[1] Java Standard Edition 8 Update Stable release 5 (1.8.0_5) / April 15, 2014; 2 months ago Static, strong, safe, nominative, Typing discipline manifest Major OpenJDK, many others implementations Dialects Generic Java, Pizza Ada 83, C++, C#,[2] Eiffel,[3] Generic Java, Mesa,[4] Modula- Influenced by 3,[5] Oberon,[6] Objective-C,[7] UCSD Pascal,[8][9] Smalltalk Ada 2005, BeanShell, C#, Clojure, D, ECMAScript, Influenced Groovy, J#, JavaScript, Kotlin, PHP, Python, Scala, Seed7, Vala Implementation C and C++ language OS Cross-platform (multi-platform) GNU General Public License, License Java CommuniCommunity Process Filename .java , .class, .jar extension(s) Website For Java Developers Java Programming at Wikibooks Java is a computer programming language that is concurrent, class-based, object-oriented, and specifically designed to have as few impimplementation dependencies as possible.ble. It is intended to let application developers "write once, run ananywhere" (WORA), meaning that code that runs on one platform does not need to be recompiled to rurun on another. Java applications ns are typically compiled to bytecode (class file) that can run on anany Java virtual machine (JVM)) regardless of computer architecture. Java is, as of 2014, one of tthe most popular programming ng languages in use, particularly for client-server web applications, witwith a reported 9 million developers.[10][11] Java was originallyy developed by James Gosling at Sun Microsystems (which has since merged into Oracle Corporation) and released in 1995 as a core component of Sun Microsystems'Micros Java platform.
    [Show full text]
  • Open Standards in Open Source Andrew Savory, Luminas
    Open Standards in Open Source Andrew Savory, Luminas 1 This is a tongue-in-cheek look at the symbiotic relationship between Open Standards and Open Source. It is designed to stimulate discussion rather than to be entirely truthful or accurate! Introduction • Andrew Savory: • OS developer for ~ 10 years • Developer on Apache Cocoon, Jackrabbit • Open Source pragmatist • Director of Luminas and Orixo 2 What are standards? • Industry standards • PDF? Word? • “open” standards • What’s the price of interoperability? • Relax-NG = £55 • Open Standards 3 The word “standard” is frequently abused, and there are several different types of “standard” in the IT industry: - Industry standards: where the market-leader uses / abuses their position to push one way of working (typically file formats) and will rarely publish the specifications for that widely-adopted “standard”. - “open” standards, which pretend to be widely available but where you have to pay the standards body to access the specifications. - Open Standards, often in the form of Recommendations (W3C) or RFQs (IETF). These are designed by experts and made available to anyone, with feedback and improvements encouraged and expected. Why Standards? • Interoperability • Competition • Security and testing 4 Why are standards important to Open Source developers? Interoperability: we aren’t interested in vendor lock-in. We want to make sure our software works with others. - even some proprietary developers understand this: a good example is Brent Simmons, author of NetNewsWire Competition: we’re a fiercely competitive lot, and we each believe we’re going to produce the best implementation. Because Open Source developers love to compete with each other, we need a frame of reference - standards set out the ground rules.
    [Show full text]
  • Proceedings of the Third Virtual Machine Research and Technology Symposium
    USENIX Association Proceedings of the Third Virtual Machine Research and Technology Symposium San Jose, CA, USA May 6–7, 2004 © 2004 by The USENIX Association All Rights Reserved For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. MCI-Java: A Modified Java Virtual Machine Approach to Multiple Code Inheritance Maria Cutumisu, Calvin Chan, Paul Lu and Duane Szafron Department of Computing Science, University of Alberta {meric, calvinc, paullu, duane}@cs.ualberta.ca Abstract Java has multiple inheritance of interfaces, but only single inheritance of code via classes. This situation results in duplicated code in Java library classes and application code. We describe a generalization to the Java language syntax and the Java Virtual Machine (JVM) to support multiple inheritance of code, called MCI-Java. Our approach places multiply-inherited code in a new language construct called an implementation, which lies between an interface and a class in the inheritance hierarchy. MCI-Java does not support multiply-inherited data, which can cause modeling and performance problems. The MCI-Java extension is implemented by making minimal changes to the Java syntax, small changes to a compiler (IBM Jikes), and modest localized changes to a JVM (SUN JDK 1.2.2). The JVM changes result in no measurable performance overhead in real applications.
    [Show full text]
  • Design and Implementation of a Scala Compiler Backend Targeting the Low Level Virtual Machine Geoffrey Reedy
    University of New Mexico UNM Digital Repository Computer Science ETDs Engineering ETDs 5-1-2014 Design and Implementation of a Scala Compiler Backend Targeting the Low Level Virtual Machine Geoffrey Reedy Follow this and additional works at: https://digitalrepository.unm.edu/cs_etds Recommended Citation Reedy, Geoffrey. "Design and Implementation of a Scala Compiler Backend Targeting the Low Level Virtual Machine." (2014). https://digitalrepository.unm.edu/cs_etds/67 This Thesis is brought to you for free and open access by the Engineering ETDs at UNM Digital Repository. It has been accepted for inclusion in Computer Science ETDs by an authorized administrator of UNM Digital Repository. For more information, please contact [email protected]. Geoffrey Reedy Candidate Computer Science Department This thesis is approved, and it is acceptable in quality and form for publication: Approved by the Thesis Committee: Darko Stefanovic , Chairperson Jed Crandall Matthew Lakin Design and Implementation of a Scala Compiler Backend Targeting the Low Level Virtual Machine by Geoffrey Reedy B.S., Computer Science, University of Missouri — Rolla, 2004 THESIS Submitted in Partial Fulfillment of the Requirements for the Degree of Master of Science Computer Science The University of New Mexico Albuquerque, New Mexico May, 2014 ©2014, Geoffrey Reedy iii Design and Implementation of a Scala Compiler Backend Targeting the Low Level Virtual Machine by Geoffrey Reedy B.S., Computer Science, University of Missouri — Rolla, 2004 M.S., Computer Science, University of New Mexico, 2014 Abstract The Scala programming language successfully blends object-oriented and functional programming. The current implementation of Scala is tied to the Java Virtual Machine (JVM) which constrains the implementation and deployment targets.
    [Show full text]
  • QUERY-DRIVEN TEXT ANALYTICS for KNOWLEDGE EXTRACTION, RESOLUTION, and INFERENCE by CHRISTAN EARL GRANT a DISSERTATION PRESENTED
    QUERY-DRIVEN TEXT ANALYTICS FOR KNOWLEDGE EXTRACTION, RESOLUTION, AND INFERENCE By CHRISTAN EARL GRANT A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY UNIVERSITY OF FLORIDA 2015 c 2015 Christan Earl Grant To Jesus my Savior, Vanisia my wife, my daughter Caliah, soon to be born son and my parents and siblings, whom I strive to impress. Also, to all my brothers and sisters battling injustice while I battled bugs and deadlines. ACKNOWLEDGMENTS I had an opportunity to see my dad, a software engineer from Jamaica work extremely hard to get a master's degree and work as a software engineer. I even had the privilege of sitting in some of his classes as he taught at a local university. Watching my dad work towards intellectual endeavors made me believe that anything is possible. I am extremely privileged to have someone I could look up to as an example of being a man, father, and scholar. I had my first taste of research when Dr. Joachim Hammer went out of his way to find a task for me on one of his research projects because I was interested in attending graduate school. After working with the team for a few weeks he was willing to give me increased responsibility | he let me attend the 2006 SIGMOD Conference in Chicago. It was at this that my eyes were opened to the world of database research. As an early graduate student Dr. Joseph Wilson exercised superhuman patience with me as I learned to grasp the fundamentals of paper writing.
    [Show full text]
  • The Java® Language Specification Java SE 8 Edition
    The Java® Language Specification Java SE 8 Edition James Gosling Bill Joy Guy Steele Gilad Bracha Alex Buckley 2015-02-13 Specification: JSR-337 Java® SE 8 Release Contents ("Specification") Version: 8 Status: Maintenance Release Release: March 2015 Copyright © 1997, 2015, Oracle America, Inc. and/or its affiliates. 500 Oracle Parkway, Redwood City, California 94065, U.S.A. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. The Specification provided herein is provided to you only under the Limited License Grant included herein as Appendix A. Please see Appendix A, Limited License Grant. To Maurizio, with deepest thanks. Table of Contents Preface to the Java SE 8 Edition xix 1 Introduction 1 1.1 Organization of the Specification 2 1.2 Example Programs 6 1.3 Notation 6 1.4 Relationship to Predefined Classes and Interfaces 7 1.5 Feedback 7 1.6 References 7 2 Grammars 9 2.1 Context-Free Grammars 9 2.2 The Lexical Grammar 9 2.3 The Syntactic Grammar 10 2.4 Grammar Notation 10 3 Lexical Structure 15 3.1 Unicode 15 3.2 Lexical Translations 16 3.3 Unicode Escapes 17 3.4 Line Terminators 19 3.5 Input Elements and Tokens 19 3.6 White Space 20 3.7 Comments 21 3.8 Identifiers 22 3.9 Keywords 24 3.10 Literals 24 3.10.1 Integer Literals 25 3.10.2 Floating-Point Literals 31 3.10.3 Boolean Literals 34 3.10.4 Character Literals 34 3.10.5 String Literals 35 3.10.6 Escape Sequences for Character and String Literals 37 3.10.7 The Null Literal 38 3.11 Separators
    [Show full text]
  • Java and C CSE351, Summer 2018
    L23: Java and C CSE351, Summer 2018 Java and C CSE 351 Summer 2018 Instructor: Justin Hsia Teaching Assistants: Josie Lee Natalie Andreeva Teagan Horkan https://xkcd.com/801/ L23: Java and C CSE351, Summer 2018 Administrivia Lab 5 due Friday (8/17) at 11:59 pm . Hard deadline Course evaluations now open . See Piazza post @120 for links Final Exam: Friday in lecture . Review Session: Wed, 8/15, 5‐6:30 pm in EEB 045 . You get ONE double‐sided handwritten 8.5 11” cheat sheet 2 L23: Java and C CSE351, Summer 2018 Roadmap C: Java: Memory & data car *c = malloc(sizeof(car)); Car c = new Car(); Integers & floats c->miles = 100; c.setMiles(100); x86 assembly c->gals = 17; c.setGals(17); Procedures & stacks float mpg = get_mpg(c); float mpg = Executables free(c); c.getMPG(); Arrays & structs Memory & caches Assembly get_mpg: Processes language: pushq %rbp movq %rsp, %rbp Virtual memory ... Memory allocation popq %rbp Java vs. C ret OS: Machine 0111010000011000 100011010000010000000010 code: 1000100111000010 110000011111101000011111 Computer system: 3 L23: Java and C CSE351, Summer 2018 Java vs. C Reconnecting to Java (hello CSE143!) . But now you know a lot more about what really happens when we execute programs We’ve learned about the following items in C; now we’ll see what they look like for Java: . Representation of data . Pointers / references . Casting . Function / method calls including dynamic dispatch 4 L23: Java and C CSE351, Summer 2018 Worlds Colliding CSE351 has given you a “really different feeling” about what computers do and how programs execute We have occasionally contrasted to Java, but CSE143 may still feel like “a different world” .
    [Show full text]
  • Building Useful Program Analysis Tools Using an Extensible Java Compiler
    Building Useful Program Analysis Tools Using an Extensible Java Compiler Edward Aftandilian, Raluca Sauciuc Siddharth Priya, Sundaresan Krishnan Google, Inc. Google, Inc. Mountain View, CA, USA Hyderabad, India feaftan, [email protected] fsiddharth, [email protected] Abstract—Large software companies need customized tools a specific task, but they fail for several reasons. First, ad- to manage their source code. These tools are often built in hoc program analysis tools are often brittle and break on an ad-hoc fashion, using brittle technologies such as regular uncommon-but-valid code patterns. Second, simple ad-hoc expressions and home-grown parsers. Changes in the language cause the tools to break. More importantly, these ad-hoc tools tools don’t provide sufficient information to perform many often do not support uncommon-but-valid code code patterns. non-trivial analyses, including refactorings. Type and symbol We report our experiences building source-code analysis information is especially useful, but amounts to writing a tools at Google on top of a third-party, open-source, extensible type-checker. Finally, more sophisticated program analysis compiler. We describe three tools in use on our Java codebase. tools are expensive to create and maintain, especially as the The first, Strict Java Dependencies, enforces our dependency target language evolves. policy in order to reduce JAR file sizes and testing load. The second, error-prone, adds new error checks to the compilation In this paper, we present our experience building special- process and automates repair of those errors at a whole- purpose tools on top of the the piece of software in our codebase scale.
    [Show full text]