DOCSLIB.ORG

Speculative Parallelization of Object-Oriented Applications

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Speculative Parallelization of Object-Oriented Applications UNIVERSIDADE DE LISBOA INSTITUTO SUPERIOR TÉCNICO Speculative Parallelization of Object-Oriented Applications Ivo Filipe Silva Daniel Anjo Supervisor: Doctor João Manuel Pinheiro Cachopo Thesis approved in public session to obtain the PhD Degree in Information Systems and Computer Engineering Jury final classification: Pass with Merit Jury Chairperson: Chairman of the IST Scientific Board Members of the Committee: Doctor Thomas Richard Gross Doctor Bruno Miguel Brás Cabral Doctor Luís Manuel Antunes Veiga Doctor João Manuel Pinheiro Cachopo 2015 UNIVERSIDADE DE LISBOA INSTITUTO SUPERIOR TÉCNICO Speculative Parallelization of Object-Oriented Applications Ivo Filipe Silva Daniel Anjo Supervisor: Doctor João Manuel Pinheiro Cachopo Thesis approved in public session to obtain the PhD Degree in Information Systems and Computer Engineering Jury final classification: Pass with Merit Jury Chairperson: Chairman of the IST Scientific Board Members of the Committee: Doctor Thomas Richard Gross, Full Professor, ETH Zürich, Switzerland Doctor Bruno Miguel Brás Cabral, Professor Auxiliar da Faculdade de Ciências e Tecnologia, Universidade de Coimbra Doctor Luís Manuel Antunes Veiga, Professor Auxiliar do Instituto Superior Técnico, Universidade de Lisboa Doctor João Manuel Pinheiro Cachopo, Professor Auxiliar do Instituto Superior Técnico, Universidade de Lisboa Funding Institutions Fundação para a Ciência e a Tecnologia 2015 Resumo Apesar da ubiquidade dos processadores multicore, e ainda que novas aplicações informáti- cas estejam a ser desenvolvidas para tirar partido das suas capacidades de processamento paralelo, muitas das aplicações mais comuns são ainda sequenciais. Como consequência, muitos dos designers de processadores, ainda que activamente publicitando e recomendando a utilização de programação paralela, dedicam ainda muitos dos seus recursos à obtenção de melhores velocidades de processamento para código sequencial. Esta persistência mostra que o desempenho na execução sequencial é ainda um importante desafio em sistemas modernos. Nesta dissertação, proponho a criação de uma framework para paralelização automática com o objectivo de acelerar a execução — em multicores — de aplicações sequenciais orientadas a objectos que se executem em plataformas managed. A natureza fortemente dinâmica e irregular deste tipo de aplicações e das plataformas em que assentam derrota muitas das técnicas tradicionais de paralelização, requerendo uma aproximação diferente para se conseguir ter sucesso. Para permitir a execução especulativa de código com baixo impacto na performance, pro- ponho um novo modelo de Memória Transaccional por Software especializado para paralelização especulativa. Para permitir à framework proposta a utilização de Especulação ao Nível do Método, proponho um novo algoritmo para transformar chamadas a métodos em pontos de início de especulação que retornam futuros. Examino ainda os problemas com filas de exe- cução e mapeamento de tarefas para threads, e introduzo um conjunto de novas técnicas que permitem reduzir os tempos de espera e que aumentam a eficiência da utilização de recursos da máquina. Finalmente, descrevo a implementação das técnicas propostas na criação de um sistema coerente — a framework JaSPEx-MLS — que proporciona uma solução integrada para a aceleração da execução de aplicações Java/JVM sequenciais em hardware comum, sem necessidade de alterações prévias às mesmas, e com performance capaz de superar JVMs comerciais. v Abstract Despite the ubiquity of multicores, and although new applications are being developed to take advantage of multicore systems, many commonly-used applications are still sequential. As a consequence, many chip designers, while actively advocating parallel programming, still dedicate many of their resources to providing faster sequential code execution. This shows that sequential code execution performance is still an important challenge for modern computing systems. In this dissertation, I propose the creation of an automatic parallelization framework that boosts the execution of sequential object-oriented applications running atop managed runtimes. The highly dynamic and irregular nature of these applications and their supporting runtimes requires a different approach to parallelization that defeats many traditional parallelization techniques. To support low-overhead speculative code execution, I propose a novel Software Transac- tional Memory model that is specialized for speculative parallelization. To allow the proposed framework to use Method-Level Speculation as a task identification strategy, I propose a new algorithm that allows the safe transformation of method call sites into spawn points that return futures. Then, I examine the issues of runtime task queuing and thread mapping, and introduce several new techniques to reduce stalling and increase resource usage efficiency. Finally, I describe the combination of the proposed techniques into a coherent system — the JaSPEx- MLS framework — that provides an end-to-end solution for boosting sequential Java/JVM applications on commodity hardware, without requiring applications to be previously modified, and yielding performance capable of surpassing production Java runtimes. vii Palavras-chave Paralelização Automática Especulação ao Nível do Método Aplicações Orientadas a Objectos Memória Transaccional em Software Máquina Virtual Java OpenJDK HotSpot Arquitecturas Multicore Keywords Automatic Parallelization Method-Level Speculation Object-Oriented Applications Software Transactional Memory OpenJDK HotSpot JVM Multicore Architectures ix Acknowledgments How much can I change on this journey? — A question that I didn’t consciously ask myself when I decided to embark on this challenge, but that I feel has been hoisted on the flagship since day one. A lot, as it turns out. I have become a better engineer, a better scientist, and a better person. The trip has been long and hard, but in the end I feel that this work is really my own, and it shows all my ideas, enthusiasm, and skills for getting it working. For a number of years I will be able to brag about knowing things about Java and the Java platform that no-one should have to know. I hope that others will be able to learn from both my successes and my mistakes, and that future research will be better off than when I started my work, all the way back in 2008. I would like to extend greetings and general kudos to my colleagues for putting up with me for the best part of 6 years (10! for some): Hugo, Stoyan, Luís and Sérgio; also other guys from ESW, GSD, the room across, and the new blood from INESC-ID room 138. I put up with you too, so don’t complain too much :) A big hug and thanks goes to Telma. Thanks for keeping me company all those lunches, thanks for kicking my butt when I deserved, and thanks for listening when I needed someone to talk to. We’re almost out of here, home stretch! I would not be here if it were not for the support from my advisor, Professor João Cachopo. His insights and steering were invaluable for the success of this work, and his technical skills and engineer mind are among the best I had the pleasure to cross paths with. I wish you the best on your UK adventure, and well, here’s hoping I’ll get to it someday too ;) Last, but by no stretch of mind least, my friends and family. Friends, past and present: Thanks are never enough. Francisco, Eduardo, Tiago, Hugo, Camila, João², Ivo, Rafael, Luena, Patrícia, Ana. I love you seems to not really cover it. As I sit here writing this text, I fail to see how these characters can convey my deep thanks for your support. You know who you are. Thanks for being a part of my life, and hope you’ve enjoyed doing so. Thanks to my younger sister, Mafalda. You’ve grown so much these past years — I have to say I kinda envy you! Thanks to my father, Carlos, and to Dulce, for believing in me and giving me a place where I can always go back to. Thanks to Mário, who doesn’t get enough credit for setting me straight one too many times and for teaching me to go further. A wink goes to Márcia, the latest entry on this list. Where were you? You almost didn’t make it in time to be present on this list, you late baka-head. I love you! xi Finally, I dedicate this dissertation to my mother, Isabel, and to my grandfather, Ivo, who are no longer amongst us. Your departure left me with great sorrow, but I like to think that you’d approve of where I am now and what I decided to do with my life. I daresay you’d be proud. Ivo Anjo July 2014 xii Contents List of Figures xvii List of Tables xix List of Listings xxi 1 Introduction 1 1.1 Thesis Statement..................................... 3 1.2 Contributions....................................... 4 1.3 Outline of the Dissertation ............................... 5 2 Motivation, Problem Statement, and Approach7 2.1 Towards the Parallelization of Object-Oriented Applications............ 8 2.2 Case Study: The Java Platform............................. 10 2.2.1 Java or JVM Applications? ............................ 10 2.3 Problem Statement.................................... 11 2.4 Approach: Creation of a Speculative Parallelization Framework.......... 12 2.4.1 Solution Overview ................................. 12 2.4.2 JaSPEx-MLS System Overview.......................... 13 2.4.3 Why Work Atop the HotSpot JVM?........................ 15 2.4.4 Method-Level Speculation............................. 16 2.4.5 Threads and Tasks................................. 17 2.5 Summary ........................................
Load more

Recommended publications
  • 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]
  • Effective Inline-Threaded Interpretation of Java Bytecode
    Effective Inline-Threaded Interpretation of Java Bytecode Using Preparation Sequences Etienne Gagnon1 and Laurie Hendren2 1 Sable Research Group Universit´eduQu´ebec `a Montr´eal, [email protected] 2 McGill University Montreal, Canada, [email protected] Abstract. Inline-threaded interpretation is a recent technique that im- proves performance by eliminating dispatch overhead within basic blocks for interpreters written in C [11]. The dynamic class loading, lazy class initialization, and multi-threading features of Java reduce the effective- ness of a straight-forward implementation of this technique within Java interpreters. In this paper, we introduce preparation sequences, a new technique that solves the particular challenge of effectively inline-threa- ding Java. We have implemented our technique in the SableVM Java virtual machine, and our experimental results show that using our tech- nique, inline-threaded interpretation of Java, on a set of benchmarks, achieves a speedup ranging from 1.20 to 2.41 over switch-based inter- pretation, and a speedup ranging from 1.15 to 2.14 over direct-threaded interpretation. 1 Introduction One of the main advantages of interpreters written in high-level languages is their simplicity and portability, when compared to static and dynamic compiler-based systems. One of their main drawbacks is poor performance, due to a high cost for dispatching interpreted instructions. In [11], Piumarta and Riccardi introduced a technique called inlined-threading which reduces this overhead by dynamically inlining instruction sequences within basic blocks, leaving a single instruction dispatch at the end of each sequence. To our knowledge, inlined-threading has not been applied to Java interpreters before.
    [Show full text]
  • Android Cours 1 : Introduction `Aandroid / Android Studio
    Android Cours 1 : Introduction `aAndroid / Android Studio Damien MASSON [email protected] http://www.esiee.fr/~massond 21 f´evrier2017 R´ef´erences https://developer.android.com (Incontournable !) https://openclassrooms.com/courses/ creez-des-applications-pour-android/ Un tutoriel en fran¸caisassez complet et plut^ot`ajour... 2/52 Qu'est-ce qu'Android ? PME am´ericaine,Android Incorporated, cr´e´eeen 2003, rachet´eepar Google en 2005 OS lanc´een 2007 En 2015, Android est le syst`emed'exploitation mobile le plus utilis´edans le monde (>80%) 3/52 Qu'est-ce qu'Android ? Cinq couches distinctes : 1 le noyau Linux avec les pilotes ; 2 des biblioth`equeslogicielles telles que WebKit/Blink, OpenGL ES, SQLite ou FreeType ; 3 un environnement d'ex´ecutionet des biblioth`equespermettant d'ex´ecuterdes programmes pr´evuspour la plate-forme Java ; 4 un framework { kit de d´eveloppement d'applications ; 4/52 Android et la plateforme Java Jusqu'`asa version 4.4, Android comporte une machine virtuelle nomm´eeDalvik Le bytecode de Dalvik est diff´erentde celui de la machine virtuelle Java de Oracle (JVM) le processus de construction d'une application est diff´erent Code Java (.java) ! bytecode Java (.class/.jar) ! bytecode Dalvik (.dex) ! interpr´et´e L'ensemble de la biblioth`equestandard d'Android ressemble `a J2SE (Java Standard Edition) de la plateforme Java. La principale diff´erenceest que les biblioth`equesd'interface graphique AWT et Swing sont remplac´eespar des biblioth`equesd'Android. 5/52 Android Runtime (ART) A` partir de la version 5.0 (2014), l'environnement d'ex´ecution ART (Android RunTime) remplace la machine virtuelle Dalvik.
    [Show full text]
  • Compiler Analyses for Improved Return Value Prediction
    Compiler Analyses for Improved Return Value Prediction Christopher J.F. Pickett Clark Verbrugge {cpicke,clump}@sable.mcgill.ca School of Computer Science, McGill University Montreal,´ Quebec,´ Canada H3A 2A7 Overview Introduction and Related Work Contributions Framework Parameter Dependence Analysis Return Value Use Analysis Conclusions Future Work CDP04 – 1/48 Introduction and Related Work Speculative method-level parallelism (SMLP) allows for dynamic parallelisation of single-threaded programs speculative threads are forked at callsites suitable for Java virtual machines Perfect return value prediction can double performance of SMLP (Hu et al., 2003) Implemented accurate return value prediction in SableVM, our group’s JVM (Pickett et al., 2004) Current goals: Reduce memory requirements Achieve higher accuracy CDP04 – 2/48 Speculative Method-Level Parallelism // execute foo non-speculatively r = foo (a, b, c); // execute past return point // speculatively in parallel with foo() if (r > 10) { ... } else { ... } CDP04 – 3/48 Impact of Return Value Prediction RVP strategy return value SMLP speedup none arbitrary 1.52 best predicted 1.92 perfect correct 2.76 26% speedup over no RVP with Hu’s best predictor 82% speedup over no RVP with perfect prediction Improved hybrid accuracy is highly desirable S. Hu., R. Bhargava, and L. K. John. The role of return value prediction in exploiting speculative method-level parallelism. Journal of Instruction-Level Parallelism, 5:1–21, Nov. 2003. CDP04 – 4/48 Return Value Prediction in SableVM Implemented all of Hu et al.’s predictors in SableVM Introduced new memoization predictor into hybrid C.J.F. Pickett and C. Verbrugge. Return value prediction in a Java virtual machine.
    [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]
  • Guideline Document and Peripheral Input/Output Libraries for Developments
    Keeping Emulation Environments Portable FP7-ICT-231954 Guideline document and peripheral input/output libraries for developments Deliverable number D 5.1 Nature Other Dissemination level PU Delivery date Due: M8 (September 2009) Actual: M8 (September 2009) Status Final Workpackage number WP5 Lead beneficiary UPHEC Author(s) Antonio Ciuffreda, UPHEC David Anderson, UPHEC Janet Delve, UPHEC Getaneh Agegn Alemu, UPHEC Dan Pinchbeck, UPHEC Bram Lohman,TSSP David Michel, TSSP Bart Kiers, KB Vincent Joguin, JOG D 5.1 Guideline document and peripheral input/output libraries for developments Document history Revisions Version Date Author Changes 0.1 3 September 2009 Bram Lohman Sections 3.2 and 3.3 0.2 5 September 2009 Vincent Joguin Section 3.3 0.3 11 September 2009 David Michel Sections 1.2, 2.1, 2.2, 2.3, 3.1.1, 3.1.2, 3.1.4, 3.2, 3.3, 4.2.1 and 4.2.7 0.4 15 September 2009 Vincent Joguin Executive Summary, Abbreviations, Sections 3.1.1 and 3.1.4 0.5 15 September 2009 David Anderson Executive Summary, Abbreviations, Sections 1, 2, 3 and 4 Reviews Date Name Result 23/09/2009 Jean Marc Saffroy Approved with changes 29/09/2009 Jeffrey van der Hoeven Approved with changes Signature/Approval Approved by (signature) Date Accepted by at European Commission (signature) Date KEEP_WP5_D5.1_Guideline-Document-and-Peripheral-Input-Output-Libraries-for-Developments_v1.0.doc 2/23 D 5.1 Guideline document and peripheral input/output libraries for developments Executive Summary This report presents the initial integration strategy of the KEEP Emulation Access Platform (EAP) components, with a focus on the methodologies used to integrate the Core Emulation Framework (CEF) with the Olonys Virtual Machine (VM), the Front-end Emulation Framework (FEF) and external web services.
    [Show full text]
  • By Mathew Zaleski a Thesis Submitted in Conformity with the Requirements
    YETI: A GRADUALLYEXTENSIBLE TRACE INTERPRETER by Mathew Zaleski A thesis submitted in conformity with the requirements for the degree of Doctor of Philosophy Graduate Department of Computer Science University of Toronto Copyright c 2008 by Mathew Zaleski Library and Archives Bibliothèque et Canada Archives Canada Published Heritage Direction du Branch Patrimoine de l’édition 395 Wellington Street 395, rue Wellington Ottawa ON K1A 0N4 Ottawa ON K1A 0N4 Canada Canada Your file Votre référence ISBN: 978-0-494-57946-6 Our file Notre référence ISBN: 978-0-494-57946-6 NOTICE: AVIS: The author has granted a non- L’auteur a accordé une licence non exclusive exclusive license allowing Library and permettant à la Bibliothèque et Archives Archives Canada to reproduce, Canada de reproduire, publier, archiver, publish, archive, preserve, conserve, sauvegarder, conserver, transmettre au public communicate to the public by par télécommunication ou par l’Internet, prêter, telecommunication or on the Internet, distribuer et vendre des thèses partout dans le loan, distribute and sell theses monde, à des fins commerciales ou autres, sur worldwide, for commercial or non- support microforme, papier, électronique et/ou commercial purposes, in microform, autres formats. paper, electronic and/or any other formats. The author retains copyright L’auteur conserve la propriété du droit d’auteur ownership and moral rights in this et des droits moraux qui protège cette thèse. Ni thesis. Neither the thesis nor la thèse ni des extraits substantiels de celle-ci substantial extracts from it may be ne doivent être imprimés ou autrement printed or otherwise reproduced reproduits sans son autorisation. without the author’s permission.
    [Show full text]
  • Return Value Prediction in a Java Virtual Machine
    Return Value Prediction in a Java Virtual Machine Christopher J.F. Pickett Clark Verbrugge School of Computer Science, McGill University Montr´eal, Qu´ebec, Canada H3A 2A7 {cpicke,clump}@sable.mcgill.ca Abstract We present the design and implementation of return value prediction in SableVM, a Java Virtual Machine. We give detailed results for the full SPEC JVM98 benchmark suite, and compare our results with previous, more lim- ited data. At the performance limit of exist- ing last value, stride, 2-delta stride, parameter stride, and context (FCM) sub-predictors in a hybrid, we achieve an average accuracy of 72%. We describe and characterize a new table-based memoization predictor that complements these predictors nicely, yielding an increased average hybrid accuracy of 81%. VM level information about data widths provides a 35% reduction in space, and dynamic allocation and expansion of per-callsite hashtables allows for highly accu- rate prediction with an average per-benchmark requirement of 119 MB for the context predic- Figure 1: (a) Sequential execution of Java bytecode. The tor and 43 MB for the memoization predictor. target method of an INVOKE<X> instruction executes before As far as we know, the is the first implementa- the instructions following the return point. (b) Speculative tion of non-trace-based return value prediction execution of Java bytecode under SMLP. Upon reaching a within a JVM. method callsite, the non-speculative parent thread T1 forks a speculative child thread T2. If the method is non-void, a predicted return value is pushed on T2’s Java stack. T2 then continues past the return point in parallel with the execu- 1 Introduction tion of the method body, buffering main memory accesses.
    [Show full text]
  • Port of the Java Virtual Machine Kaffe to DROPS by Using L4env
    Port of the Java Virtual Machine Kaffe to DROPS by using L4Env Alexander B¨ottcher [email protected] Technische Universit¨atDresden Faculty of Computer Science Operating System Group July 2004 Contents 1 Motivation 3 2 Fundamentals 4 2.1 Dresden Real-Time Operating System . 4 2.1.1 Microkernel . 4 2.1.2 L4Env - an environment on top of the L4 kernel . 5 2.2 Java and Java Virtual Machines . 6 2.2.1 Architecture . 6 2.2.2 Available Java Virtual Machines . 7 2.2.3 Kaffe . 8 2.3 Decision for Kaffe . 9 3 Design 10 3.1 Concepts . 10 3.2 Threads . 10 3.2.1 Thread mappings . 11 3.2.2 Adaptation of the L4Env thread library to Kaffe . 13 3.2.3 Garbage Collector . 14 3.2.4 Priorities and Scheduling . 15 3.3 Critical sections . 16 3.4 Java exception handling . 17 3.4.1 Null object and null pointer handling . 18 3.4.2 Arithmetic exception handling . 20 3.5 Memory and files . 20 3.6 Java native interface (JNI) and shared native libraries . 21 4 Implementation 22 4.1 Kaffes configuration and build system . 22 4.2 Thread data structure management . 22 4.3 Delaying of newly created threads . 23 4.4 Suspending and resuming threads . 23 1 CONTENTS 4.4.1 Stopping all threads . 24 4.4.2 Resuming all threads . 25 4.5 Semaphore problems with timing constraints . 26 4.5.1 Deadlocks caused by semaphore down timed . 26 4.5.2 Incorrect admissions to enter a semaphore .
    [Show full text]
  • Relative Factors in Performance Analysis of Java Virtual Machines
    Relative Factors in Performance Analysis of Java Virtual Machines Dayong Gu Clark Verbrugge Etienne M. Gagnon School of Computer Science D´epartement d’informatique McGill University Universit´eduQu´ebeca ` Montr´eal Montr´eal, Qu´ebec, Canada Montr´eal, Qu´ebec, Canada {dgu1, clump}@cs.mcgill.ca [email protected] Abstract perturbing performance measurements. This resulting lack of guid- Many new Java runtime optimizations report relatively small, ance often means that optimization researchers do not always give single-digit performance improvements. On modern virtual and a sufficiently wide or deep consideration to potential confounding actual hardware, however, the performance impact of an optimiza- factors from the underlying systems. tion can be influenced by a variety of factors in the underlying In this paper we focus on two main concerns. First, an expo- systems. Using a case study of a new garbage collection optimiza- sition of various external, and benchmark specific factors that can tion in two different Java virtual machines, we show the relative influence a VM or source-level optimization, and second a quanti- effects of issues that must be taken into consideration when claim- tative evaluation and comparison of the different influences. Using ing an improvement. We examine the specific and overall perfor- an in-depth case study of a simple garbage collection optimization mance changes due to our optimization and show how unintended we are able to show that a combination of instruction cache changes side-effects can contribute to, and distort the final assessment. Our due to trivial code modifications, and subtle, consequent data lay- experience shows that VM and hardware concerns can generate out and usage differences can induce almost a 10% whole program variances of up to 9.5% in whole program execution time.
    [Show full text]
  • Bootstrappable Builds
    Bootstrappable builds Ricardo Wurmus September 18, 2017 Recipe for yoghurt: add yoghurt to milk I “yoghurt software” undermines software freedom I ignore: use existing binaries to build new binaries I retrace history, save old tools from bit rot I write new alternative language implementations Java I JDK is written in Java I GCJ needs ECJ (Java), bundles pre-compiled GNU Classpath :-( JDK bootstrap 1. Jikes (C++) -> SableVM (Java + C) 2. old Ant (Java) -> old ECJ (Java) 3. ECJ -> GNU Classpath 0.99 -> JamVM 4. JamVM -> GNU Classpath devel (for Java ~1.6) -> JamVM’ 5. OpenJDK via IcedTea 1.x -> 2.x -> 3.x Java libraries I cultural problem: download/bundle pre-built packages I only leaf nodes are built from source I dependency cycles are common I cannot use modern build tools I needs lots of patience Haskell I All versions of GHC are written in Haskell I need GHC (n-1) to build GHC n I history is littered with defunct Haskell systems: nhc98, Yale Haskell, Hugs I failed: use Hugs to build nhc98 to build GHC see: https://elephly.net/posts/ 2017-01-09-bootstrapping-haskell-part-1.html I next: use Hugs interpreter to build patched GHC directly I future: revive and extend Yale Haskell? The elephant in the room. [width=.9]./elephly GCC I needs C++ compiler since version 4.7 I is there a path from reasonably auditable source to GCC? Stage0 and Mes Stage0 https://git.savannah.nongnu.org/git/stage0.git I hex.0: self-hosting hex assembler that we consider to be source (< 300 bytes) I M0 macro assembler written in .0 I M1 macro assembler written in
    [Show full text]
  • Resource Accounting and Reservation in Java Virtual Machine
    Resource accounting and reservation in Java Virtual Machine Inti Gonzalez-Herrera, Johann Bourcier, Olivier Barais January 24, 2013 1 The Java platform The Java programming language was designed to developed small application for embedded devices, but it was a long time ago. Today, Java application are running in many platforms ranging from smartphones to enterprise servers. Modern pervasive middleware is typically implemented using Java because of its safety, flexibility, and mature development environment. However, the Java virtual machine specification has not had a major revised since 1999 [50]. It was designed to execute only a single application per instances, and thus it does not provide resource accounting or per-application resource reservations in the sense most middlewares consider application. Often, current pervasive middlewares are thus unable to reserve resources for critical applications, which may cause these applications to crash or hang up when there are not enough resources. Moreover, contemporary middlewares are unable to provide resource accounting. It makes impossible to apply adaptation policies to optimize resource use. Several researches had addressed these important issues. As result of these efforts some Java spec- ification requests (JSR) have emerged. We consider there are seven JSRs relate to monitoring and to resource accounting and reservation: three for the Java Management eXtension API (JSRs 3, 160, 255), two for Metric Instrumentation (JSRs 138, 174) and two for resource-consumption management (JSRs 121, 284). The Java Management extension API only addresses monitoring and management: it does not define specific resource accounting or reservation strategies. JSRs 138 and 174 define monitors for the Java Virtual Machine.
    [Show full text]