DOCSLIB.ORG

Combining Speculative Optimizations with Flexible Scheduling of Side-Effects

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Combining Speculative Optimizations with Flexible Scheduling of Side-Effects Combining Speculative Optimizations with Flexible Scheduling of Side-effects DISSERTATION submitted in partial fulfillment of the requirements for the academic degree Doktor der Technischen Wissenschaften in the Doctoral Program in Engineering Sciences Submitted by: Gilles Marie Duboscq At the: Institute for System Software Accepted on the recommendation of: Univ.-Prof. Dipl.-Ing. Dr. Dr.h.c. Hanspeter Mössenböck Dr. Laurence Tratt Linz, April 2016 Oracle, Java, HotSpot, and all Java-based trademarks are trademarks or registered trademarks of Oracle in the United States and other countries. All other product names mentioned herein are trademarks or registered trademarks of their respective owners. Eidesstattliche Erklärung Ich erkläre an Eides statt, dass ich die vorliegende Dissertation selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt bzw. die wörtlich oder sinngemäß entnommenen Stellen als solche kenntlich gemacht habe. Die vorliegende Dissertation ist mit dem elektronisch übermittelten Textdokument identisch. Linz, April 2016 Gilles Marie Duboscq Abstract Speculative optimizations allow compilers to optimize code based on assumptions that cannot be verified at compile time. Taking advantage of the specific run-time situation opensmore optimization possibilities. Speculative optimizations are key to the implementation of high- performance language runtimes. Using them requires cooperation between the just-in-time compilers and the runtime system and influences the design and the implementation of both. New speculative optimizations as well as their application in more dynamic languages are using these systems much more than current implementations were designed for. We first quantify the run time and memory footprint caused by their usage. We then propose a structure for compilers that separates the compilation process into two stages. It helps to deal with this issues without giving up on other traditional optimizations. In the first stage, floating guards can be inserted for speculative optimizations. Then the guards are fixedinthe control-flow at appropriate positions. In the second stage, side-effecting instructions can bemoved or reordered. Using this framework we present two optimizations that help reduce the run-time costs and the memory footprint. We study the effects of both stages as well as the effects of these two optimizations inthe Graal compiler. We evaluate this on classical benchmarks targeting the JVM: SPECjvm2008, DaCapo and Scala-DaCapo. We also evaluate JavaScript benchmarks running on the Truffle platform that uses the Graal compiler. We find that combining both stages can bring upto 84 % improvement in performance (9 % on average) and our optimization of memory footprint can bring memory usage down by 27 % to 92 %(45 % on average). Kurzfassung Spekulative Optimierungen sind Optimierungen des Quellcodes, welche auf Annahmen basieren die nicht zur Compile-Zeit ausgewertet werden können. Sie können spezielle Laufzeit-Situationen optimieren, die im allgemeinen Fall nicht optimierbar sind. Für die Performanz einer Laufzeitum- gebung für höhere Programmiersprachen sind spekulative Optimierungen essenziell. Für diese Optimierungen müssen der Just-in-Time-Compiler und die Laufzeitumgebung eng zusammenar- beiten, was beim Design und bei der Umsetzung der beiden Komponenten berücksichtigt werden muss. Bei solchen neuen, spekulativen Optimierungen und deren Anwendung in hoch dynamischen Sprachen kann es zu einer hohen Belastung des Compilers und der Laufzeitumgebung kommen, da diese ursprünglich nicht für solche Optimierungen konzipiert wurden. Zuerst werden die Auswirkungen solcher spekulativen Optimierungen auf die Laufzeit und das Speicherverhalten quantifiziert. Anschließend wird ein neues Compiler-Design vorgestellt, in welchem die Übersetzung eines Programms in zwei Stufen stattfindet. Dadurch können die Probleme, die bei den neuen Optimierungen auftreten, umgangen werden, ohne bestehende Optimierungen negativ zu beinflussen. In der ersten Stufe können Laufzeit-Guards fürdie spekulativen Optimierungen eingeführt werden, welche ihre Position im Kontrollfluss noch ändern können. Am Ende der ersten Stufe werden diese Guards im Kontrollfluss fixiert. In der zweiten Stufe können Anweisungen mit Nebeneffekten verschoben oder umsortiert werden. Mittels dieses Frameworks werden zwei Optimierungen präsentiert, die zum einen die Laufzeit un zum anderen den Speicherverbrauch verringern. Diese Arbeit untersucht die Auswirkungen der oben beschriebenen Stufen und die Aus- wirkungen der beiden Optimierungen im Kontext des Graal-Compilers. Folgende Benchmarks wurden zur Auswertung verwendet: SPECjvm2008, DaCapo und Scala-DaCapo. Zudem werden Javascript-Benchmarks verwendet, die auf der Truffle-Plattform laufen, welche wiederum den Graal-Compiler verwendet. Wenn beide Stufen kombiniert werden, kann die Laufzeit zum bis 84 % verringert werden (im Durchschnitt 9 %). Die Speicheroptimierung kann den Speicherverbrauch von 27 % bis 92 % verringern (im Durchschnitt 45 %). Contents 1 Introduction 1 1.1 Research Context . 1 1.2 Problem Statement . 1 1.2.1 Existing Solutions . 2 1.2.2 Current Problems . 3 1.2.3 Proposed Solution . 3 1.3 Scientific Contributions . .3 1.4 Project Context . 4 1.5 Structure of this Thesis . 5 2 Background 7 2.1 Java and the Java Virtual Machine . 7 2.2 The HotSpot Java Virtual Machine . 8 2.2.1 Deoptimization . 9 2.3 The Graal Compiler . 10 2.3.1 Overall Design . 10 2.3.2 Intermediate Representation . 12 2.3.3 Snippets . 19 2.4 Truffle . 22 3 Opportunities for Speculative Optimizations 25 3.1 Traditional Usages of Speculation . 25 3.1.1 Exception Handling . 25 3.1.2 Unreached Code . 27 3.1.3 Type Assumptions . 28 3.1.4 Loop Safepoint Checks Elimination . 29 3.2 Advanced Usages of Speculation . 29 3.2.1 Speculative Alias Analysis . 30 3.2.2 Speculative Store Checks . 30 3.2.3 Speculative Guard Motion . 31 3.2.4 Truffle . 31 4 The Costs of Speculation 35 iii Contents 4.1 Runtime Costs . 35 4.1.1 Assumptions vs. Guards . 36 4.2 Memory Footprint . 38 4.2.1 Experimental Data . 38 4.3 Managing Deoptimization Targets . 43 4.3.1 Java Memory Model Constraints . 43 4.3.2 Deoptimizing to the Previous Side-effect . 45 4.3.3 Fixed Deoptimizations . 46 4.4 Conclusion . 47 5 Optimization Stages 49 5.1 First Stage: Optimizing Guards . 50 5.1.1 Representation . 50 5.1.2 Optimizations . 50 5.2 Stage Transition . 52 5.2.1 Guard Lowering . 52 5.2.2 FrameState Assignment . 53 5.3 Second Stage: Optimizing Side-effecting Nodes . 56 6 Case Studies 59 6.1 Speculative Guard Motion . 59 6.1.1 Rewriting Bounds Checks in Loops . 60 6.1.2 Speculation Log . 62 6.1.3 Policy . 64 6.1.4 Processing Order . 64 6.2 Deoptimization Grouping . 67 6.2.1 Relation with Deoptimization Metadata Compression . 68 6.3 Vectorization . 69 7 Evaluation 73 7.1 Methodology . 73 7.1.1 Benchmarks . 73 7.1.2 Baseline . 75 7.2 Compilation Stages . 75 7.2.1 Effects of the First Stage . 75 7.2.2 Effects of the Second Stage . 81 7.3 Speculative Guard Motion . 83 7.4 Comparison to Other Compilers . 87 7.4.1 C1 . 88 7.4.2 C2 . 88 7.5 Deoptimization Grouping . 91 7.5.1 Debug Information Sharing . 91 7.6 Deoptimization Grouping without Debug Information Sharing . 94 iv Contents 7.6.1 Combining Debug Information Sharing and Deoptimiza- tion Grouping . 94 8 Related Work 97 8.1 Intermediate Representations . 97 8.2 Deoptimization . 98 8.2.1 Exception Handling . 99 8.3 Speculative Guard Motion . 100 8.4 Deoptimization Data . 100 8.4.1 Delta encoding . 100 8.4.2 Deoptimization Metadata Size . 101 8.4.3 Deoptimizing with Metadata vs. with Specialized Code 101 9 Summary 103 9.1 Future Work . 103 9.2 Conclusion . 104 List of Figures 107 List of Tables 109 List of Listings 111 List of Algorithms 113 Bibliography 115 v Acknowledgments I thank my advisor, Professor Hanspeter Mössenböck for his valuable feed- back, for welcoming me in the System Software institute and for his patience throughout the process. I also thank my second advisor, Dr Laurence Tratt for his comments. Both their efforts helped greatly in improving the quality of my thesis. I thank Oracle Labs for funding my work and supporting many other academic projects at the System Software institute. In particular, I thank the VM research group who has allowed me to work of such an interesting subject. I was extremely lucky to be part of the Graal project from the start and to see it take shape. I thank the people I met between Oracle Labs and the System Software institute: Thomas Würthinger without whom this project would not have been possible, but also Lukas Stadler, Doug Simon, Bernhard Urban, Tom Rodriguez, Stefan Marr, Andreas Wöß, Christian Wimmer and Felix Kaser for sharing ideas and enriching discussions. I thank my parents, Bertrand and Béatrice and my family, in particular my godmother Lise, for supporting and encouraging me throughout my life and in these studies. Finally, I thank Aga for her support and patience during this process. vii Chapter 1 Introduction 1.1 Research Context Programming language implementations can divide their work between a preparation step that runs before the program starts and an execution step that happens when the program is running. Unless the program is trivial, there is always work to be done at run time. At the very least, the program must run. However the amount of work done ahead of runtime varies a lot. Some language implementations do as much work as possible during the preparation step and compile the program down to a binary that can be run by the target computer. On the other hand, some language implementations do not perform any preparation at all and do everything at runtime. This is often the case for the implementation of programming languages that use a lot of dynamic features. Program optimization is almost ubiquitous in implementations that con- centrate on the preparatory phase. Optimizing compilers use extensive static analysis to try to produce a binary form of the program that executes as fast as possible.
Load more

Recommended publications
  • Bypassing Portability Pitfalls of High-Level Low-Level Programming
    Bypassing Portability Pitfalls of High-level Low-level Programming Yi Lin, Stephen M. Blackburn Australian National University [email protected], [email protected] Abstract memory-safety, encapsulation, and strong abstraction over hard- Program portability is an important software engineering consider- ware [12], which are desirable goals for system programming as ation. However, when high-level languages are extended to effec- well. Thus, high-level languages are potential candidates for sys- tively implement system projects for software engineering gain and tem programming. safety, portability is compromised—high-level code for low-level Prior research has focused on the feasibility and performance of programming cannot execute on a stock runtime, and, conversely, applying high-level languages to system programming [1, 7, 10, a runtime with special support implemented will not be portable 15, 16, 21, 22, 26–28]. The results showed that, with proper ex- across different platforms. tension and restriction, high-level languages are able to undertake We explore the portability pitfall of high-level low-level pro- the task of low-level programming, while preserving type-safety, gramming in the context of virtual machine implementation tasks. memory-safety, encapsulation and abstraction. Notwithstanding the Our approach is designing a restricted high-level language called cost for dynamic compilation and garbage collection, the perfor- RJava, with a flexible restriction model and effective low-level ex- mance of high-level languages when used to implement a virtual tensions, which is suitable for different scopes of virtual machine machine is still competitive with using a low-level language [2]. implementation, and also suitable for a low-level language bypass Using high-level languages to architect large systems is bene- for improved portability.
    [Show full text]
  • Here I Led Subcommittee Reports Related to Data-Intensive Science and Post-Moore Computing) and in CRA’S Board of Directors Since 2015
    Vivek Sarkar Curriculum Vitae Contents 1 Summary 2 2 Education 3 3 Professional Experience 3 3.1 2017-present: College of Computing, Georgia Institute of Technology . 3 3.2 2007-present: Department of Computer Science, Rice University . 5 3.3 1987-2007: International Business Machines Corporation . 7 4 Professional Awards 11 5 Research Awards 12 6 Industry Gifts 15 7 Graduate Student and Other Mentoring 17 8 Professional Service 19 8.1 Conference Committees . 20 8.2 Advisory/Award/Review/Steering Committees . 25 9 Keynote Talks, Invited Talks, Panels (Selected) 27 10 Teaching 33 11 Publications 37 11.1 Refereed Conference and Journal Publications . 37 11.2 Refereed Workshop Publications . 51 11.3 Books, Book Chapters, and Edited Volumes . 58 12 Patents 58 13 Software Artifacts (Selected) 59 14 Personal Information 60 Page 1 of 60 01/06/2020 1 Summary Over thirty years of sustained contributions to programming models, compilers and runtime systems for high performance computing, which include: 1) Leading the development of ASTI during 1991{1996, IBM's first product compiler component for optimizing locality, parallelism, and the (then) new FORTRAN 90 high-productivity array language (ASTI has continued to ship as part of IBM's XL Fortran product compilers since 1996, and was also used as the foundation for IBM's High Performance Fortran compiler product); 2) Leading the research and development of the open source Jikes Research Virtual Machine at IBM during 1998{2001, a first-of-a-kind Java Virtual Machine (JVM) and dynamic compiler implemented
    [Show full text]
  • Techniques for Real-System Characterization of Java Virtual Machine Energy and Power Behavior Gilberto Contreras Margaret Martonosi
    Techniques for Real-System Characterization of Java Virtual Machine Energy and Power Behavior Gilberto Contreras Margaret Martonosi Department of Electrical Engineering Princeton University 1 Why Study Power in Java Systems? The Java platform has been adopted in a wide variety of devices Java servers demand performance, embedded devices require low-power Performance is important, power/energy/thermal issues are equally important How do we study and characterize these requirements in a multi-layer platform? 2 Power/Performance Design Issues Java Application Java Virtual Machine Operating System Hardware 3 Power/Performance Design Issues Java Application Garbage Class Runtime Execution Collection LoaderJava VirtualCompiler MachineEngine Operating System Hardware How do the various software layers affect power/performance characteristics of hardware? Where should time be invested when designing power and/or thermally aware Java virtual Machines? 4 Outline Approaches for Energy/Performance Characterization of Java virtual machines Methodology Breaking the JVM into sub-components Hardware-based power/performance characterization of JVM sub-components Results Jikes & Kaffe on Pentium M Kaffe on Intel XScale Conclusions 5 Power & Performance Analysis of Java Simulation Approach √ Flexible: easy to model non-existent hardware x Simulators may lack comprehensiveness and accuracy x Thermal studies require tens of seconds granularity Accurate simulators are too slow Hardware Approach √ Able to capture full-system characteristics
    [Show full text]
  • Fedora Core, Java™ and You
    Fedora Core, Java™ and You Gary Benson Software Engineer What is Java? The word ªJavaº is used to describe three things: The Java programming language The Java virtual machine The Java platform To support Java applications Fedora needs all three. What Fedora uses: GCJ and ECJ GCJ is the core of Fedora©s Java support: GCJ includes gcj, a compiler for the Java programming language. GCJ also has a runtime and class library, collectively called libgcj. The class library is separately known as GNU Classpath. ECJ is the Eclipse Compiler for Java: GCJ©s compiler gcj is not used for ªtraditionalº Java compilation. More on that later... Why libgcj? There are many free Java Virtual machines: Cacao, IKVM, JamVM, Jikes RVM, Kaffe, libgcj, Sable VM, ... There are two main reasons Fedora uses libgcj: Availability on many platforms. Ability to use precompiled native code. GNU Classpath Free core class library for Java virtual machines and compilers. The JPackage Project A collection of some 1,600 Java software packages for Linux: Distribution-agnostic RPM packages. Both runtimes/development kits and applications. Segregation between free and non-free packages. All free packages built entirely from source. Multiple runtimes/development kits may be installed. Fedora includes: JPackage-compatible runtime and development kit packages. A whole bunch of applications. JPackage JOnAS Fedora©s Java Compilers gcj can operate in several modes: Java source (.java) to Java bytecode (.class) Java source (.java) to native machine code (.o) Java bytecode (.class, .jar) to native machine code (.o) In Fedora: ECJ compiles Java source to bytecode. gcj compiles that bytecode to native machine code.
    [Show full text]
  • Java in Embedded Linux Systems
    Java in Embedded Linux Systems Java in Embedded Linux Systems Thomas Petazzoni / Michael Opdenacker Free Electrons http://free-electrons.com/ Created with OpenOffice.org 2.x Java in Embedded Linux Systems © Copyright 2004-2007, Free Electrons, Creative Commons Attribution-ShareAlike 2.5 license http://free-electrons.com Sep 15, 2009 1 Rights to copy Attribution ± ShareAlike 2.5 © Copyright 2004-2008 You are free Free Electrons to copy, distribute, display, and perform the work [email protected] to make derivative works to make commercial use of the work Document sources, updates and translations: Under the following conditions http://free-electrons.com/articles/java Attribution. You must give the original author credit. Corrections, suggestions, contributions and Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license translations are welcome! identical to this one. For any reuse or distribution, you must make clear to others the license terms of this work. Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above. License text: http://creativecommons.org/licenses/by-sa/2.5/legalcode Java in Embedded Linux Systems © Copyright 2004-2007, Free Electrons, Creative Commons Attribution-ShareAlike 2.5 license http://free-electrons.com Sep 15, 2009 2 Best viewed with... This document is best viewed with a recent PDF reader or with OpenOffice.org itself! Take advantage of internal
    [Show full text]
  • Design and Analysis of a Scala Benchmark Suite for the Java Virtual Machine
    Design and Analysis of a Scala Benchmark Suite for the Java Virtual Machine Entwurf und Analyse einer Scala Benchmark Suite für die Java Virtual Machine Zur Erlangung des akademischen Grades Doktor-Ingenieur (Dr.-Ing.) genehmigte Dissertation von Diplom-Mathematiker Andreas Sewe aus Twistringen, Deutschland April 2013 — Darmstadt — D 17 Fachbereich Informatik Fachgebiet Softwaretechnik Design and Analysis of a Scala Benchmark Suite for the Java Virtual Machine Entwurf und Analyse einer Scala Benchmark Suite für die Java Virtual Machine Genehmigte Dissertation von Diplom-Mathematiker Andreas Sewe aus Twistrin- gen, Deutschland 1. Gutachten: Prof. Dr.-Ing. Ermira Mezini 2. Gutachten: Prof. Richard E. Jones Tag der Einreichung: 17. August 2012 Tag der Prüfung: 29. Oktober 2012 Darmstadt — D 17 For Bettina Academic Résumé November 2007 – October 2012 Doctoral studies at the chair of Prof. Dr.-Ing. Er- mira Mezini, Fachgebiet Softwaretechnik, Fachbereich Informatik, Techni- sche Universität Darmstadt October 2001 – October 2007 Studies in mathematics with a special focus on com- puter science (Mathematik mit Schwerpunkt Informatik) at Technische Uni- versität Darmstadt, finishing with a degree of Diplom-Mathematiker (Dipl.- Math.) iii Acknowledgements First and foremost, I would like to thank Mira Mezini, my thesis supervisor, for pro- viding me with the opportunity and freedom to pursue my research, as condensed into the thesis you now hold in your hands. Her experience and her insights did much to improve my research as did her invaluable ability to ask the right questions at the right time. I would also like to thank Richard Jones for taking the time to act as secondary reviewer of this thesis.
    [Show full text]
  • Full-System Simulation of Java Workloads with RISC-V and the Jikes Research Virtual Machine
    Full-System Simulation of Java Workloads with RISC-V and the Jikes Research Virtual Machine Martin Maas Krste Asanović John Kubiatowicz University of California, Berkeley University of California, Berkeley University of California, Berkeley [email protected] [email protected] [email protected] ABSTRACT architecture research. Specifically, all of the major approaches fall Managed languages such as Java, JavaScript or Python account for short when applied to managed-language applications: a large portion of workloads, both in cloud data centers and on • High-level full-system simulators do not provide the fidelity mobile devices. It is therefore unsurprising that there is an inter- to fully capture managed-language workloads. These work- est in hardware-software co-design for these languages. However, loads often interact at very small time-scales. For example, existing research infrastructure is often unsuitable for this kind of garbage collectors may introduce small delays of ≈ 10 cycles research: managed languages are sensitive to fine-grained inter- each, scattered through the application [10]. Cumulatively, actions that are not captured by high-level architectural models, these delays add up to substantial overheads but individually, yet are also too long-running and irregular to be simulated using they can only be captured with a high-fidelity model. cycle-accurate software simulators. • Software-based cycle-accurate simulators are too slow for Open-source hardware based on the RISC-V ISA provides an managed workloads. These simulators typically achieve on opportunity to solve this problem, by running managed workloads the order of 400 KIPS [17], or 1s of simulated time per 1.5h on RISC-V systems in FPGA-based full-system simulation.
    [Show full text]
  • A Deployable Sampling Strategy for Data Race Detection
    A Deployable Sampling Strategy for Data Race Detection Yan Cai1, Jian Zhang1, Lingwei Cao1, and Jian Liu2 1 State Key Laboratory of Computer Science, Institute of Software, Chinese Academy of Sciences, Beijing, China 2 Institute of Information Engineering, Chinese Academy of Sciences, Beijing, China [email protected], [email protected], [email protected], [email protected] ABSTRACT to a shared memory location should be protected by a common set Dynamic data race detection incurs heavy runtime overheads. of locks. However, even violating such a discipline, no data race Recently, many sampling techniques have been proposed to detect may occur [8][12][19]. The Happens-before relation [29] is usual- data races. However, some sampling techniques (e.g., Pacer) are ly implemented via vector clocks [19]. Each vector clock contains based on traditional happens-before relation and incur a large n clock elements, where n is the number of threads. They are used basic overhead. Others utilize hardware to reduce their sampling to track statuses of threads, locks, and memory locations. Race overhead (e.g., DataCollider) and they, however, detect a race detectors implementing vector clocks incur higher overhead than only when the race really occurs by delaying program executions. the lockset based ones. FastTrack [19] further improves the over- In this paper, we study the limitations of existing techniques and head of the happens-before based race detectors to be the same propose a new data race definition, named as Clock Races, for low level as that of lockset based ones by avoiding most of O(n) oper- overhead sampling purpose.
    [Show full text]
  • Jikes RVM and IBM DK for Java ƒ Understanding System Behavior ƒ Other Issues 4
    Dynamic Compilation and Adaptive Optimization in Virtual Machines Instructor: Michael Hind Material contributed by: Matthew Arnold, Stephen Fink, David Grove, and Michael Hind © 2006 IBM Corporation IBM Research Who am I? Helped build Jikes RVM (1998-2006) – GC Maps, live analysis, dominators, register allocation refactoring – Adaptive optimization system – Management, project promotion, education, etc. Work for IBM, home of 2 other Java VMs – IBM DK for Java, J9 In previous lives, worked on – Automatic parallelization (PTran) – Ada implementation (Phd Thesis) – Interprocedural ptr analysis – Professor for 6 years Excited to share what I know – And learn what I don’t! 2 ACACES’06 | Dynamic Compilation and Adaptive Optimization in Virtual Machines | July 24-28, 2006 © 2006 IBM Corporation IBM Research Course Goals Understand the optimization technology used in production virtual machines Provide historical context of dynamic/adaptive optimization technology Debunk common misconceptions Suggest avenues of future research 3 ACACES’06 | Dynamic Compilation and Adaptive Optimization in Virtual Machines | July 24-28, 2006 © 2006 IBM Corporation IBM Research Course Outline 1. Background 2. Engineering a JIT Compiler 3. Adaptive Optimization 4. Feedback-Directed and Speculative Optimizations 5. Summing Up and Looking Forward 4 ACACES’06 | Dynamic Compilation and Adaptive Optimization in Virtual Machines | July 24-28, 2006 © 2006 IBM Corporation IBM Research Course Outline 1. Background Why software optimization matters Myths, terminology, and historical context How programs are executed 2. Engineering a JIT Compiler What is a JIT compiler? Case studies: Jikes RVM, IBM DK for Java, HotSpot High level language-specific optimizations VM/JIT interactions 3. Adaptive Optimization Selective optimization Design: profiling and recompilation Case studies: Jikes RVM and IBM DK for Java Understanding system behavior Other issues 4.
    [Show full text]
  • Code Coagulation Is an Effective Compilation Technique
    CODE COAGULATION IS AN EFFECTIVE COMPILATION TECHNIQUE FOR THE JVM by Shruthi Padmanabhan Bachelor of Engineering in Information Science, Visvesvaraya Technological University, 2009 A thesis presented to Ryerson University in partial fulfillment of the requirements for the degree of Master of Science in the program of Computer Science Toronto, Ontario, Canada, 2018 c Shruthi Padmanabhan, 2018 Author's Declaration I hereby declare that I am the sole author of this thesis. This is a true copy of the thesis, including any required final revisions, as accepted by my examiners. I authorize Ryerson University to lend this thesis to other institutions or individuals for the purpose of scholarly research. I further authorize Ryerson University to reproduce this thesis by photocopying or by other means, in total or in part, at the request of other institutions or individuals for the purpose of scholarly research. I understand that my thesis may be made electronically available to the public for the purpose of scholarly research only. ii Abstract CODE COAGULATION IS AN EFFECTIVE COMPILATION TECHNIQUE FOR THE JVM Shruthi Padmanabhan Master of Science, Computer Science Ryerson University, 2018 Compilers are the interface between programmers and computers. The output of a com- piler determines the speed of the resulting program as well as its energy footprint { of increasing importance in this world of climate change and battery-dependent computing. Code coagulation has the potential to improve that performance, particularly relative to (JIT) interpreters. Java and related languages are in wide use, so addressing their per- formance has large potential impact. Optijava is an experimental compiler that applies code coagulation to Java programs.
    [Show full text]
  • Valor: Efficient, Software-Only Region Conflict Exceptions ∗
    Valor: Efficient, Software-Only Region Conflict Exceptions ∗ Swarnendu Biswas Minjia Zhang Michael D. Bond Brandon Lucia Ohio State University Carnegie Mellon University {biswass,zhanminj,mikebond}@cse.ohio-state.edu [email protected] rtifact A Comple * t * te n * A * te is W E s A e n C l l L o D C S o * * c P u e m s E u O e e n v R t e O o d t a y * s E a * l u d a e t Abstract 1. Introduction Data races complicate programming language semantics, and Data races are a fundamental barrier to providing well- a data race is often a bug. Existing techniques detect data defined programming language specifications and to writing races and define their semantics by detecting conflicts be- correct shared-memory, multithreaded programs. A data race tween synchronization-free regions (SFRs). However, such occurs when two accesses to the same memory location are techniques either modify hardware or slow programs dramat- conflicting—executed by different threads and at least one ically, preventing always-on use today. is a write—and concurrent—not ordered by synchronization This paper describes Valor, a sound, precise, software- operations [4]. only region conflict detection analysis that achieves high Data races can cause programs to exhibit confusing and performance by eliminating the costly analysis on each incorrect behavior. They can lead to sequential consistency read operation that prior approaches require. Valor instead (SC), atomicity, and order violations [42, 54] that may corrupt logs a region’s reads and lazily detects conflicts for logged data, cause a crash, or prevent forward progress [28, 36, 52].
    [Show full text]
  • GNU Classpath
    GNU Classpath Core Classes for a Diversity of Java Virtual Machines February 2004 ■ Sascha Brawer [email protected] http://www.dandelis.ch/people/brawer/ ■ Mark Wielaard [email protected] http://www.klomp.org/mark/ Overview ■ Overview – Motivation – Anatomy of a Java-like system – Documentation, Quality assurance, Releases ■ Demo ■ Details – Current state – VMs using GNU Classpath ■ How you can help 2 Motivation ■ Currently, most free software is written in C The Good The Bad The Ugly Close to hardware Easy to make bugs Libraries not Fast execution, even Lacks “modern” well integrated with bad compilers language concepts Difficult to learn Large code base, (“modern” = 1980’ies) many libraries Hard to write Ubiquitous portable code 3 Motivation ■ Java is a good foundation for many projects – Type-safety ● Avoids many typical bugs, crashes, security problems ● More opportunities for optimizing compilers – Modular, object-oriented, concurrent, dynamic – Easier to write structured, portable code – Very rich library, reasonably well designed (mostly) – Large developer base (“COBOL of the 1990’ies”) ● There exist lots of other good (even better?) languages: Oberon, Eiffel, O’Caml, Haskell, Erlang, TOM, Cedar, ... ● But: They have not many free applications/libraries 4 Motivation ■ But: Java does not solve every problem – Over-hyped as a solution to everything – Bad reputation for wasting resources (CPU, RAM) ● It is easy to write inefficient programs ● Early implementations were very slow ● Type-safety and memory management have their cost – Often over-estimated: Array bounds checking (→ no buffer overflows) costs ~2% execution time, avoids ~50% security-related bugs – Syntax similar to C++ → not very easy to learn 5 Motivation ■ Java is a compromise Why GNU Will Be – Not necessarily ideal, Compatible with UNIX but reasonable Unix is not my ideal system, but it is not too bad.
    [Show full text]