DOCSLIB.ORG

A Stack Hybridization for Meta-Hybrid Just-In-Time Compilation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Stack Hybridization for Meta-Hybrid Just-In-Time Compilation 日本ソフトウェア科学会第 36 回大会 (2019 年度) 講演論文集 A Stack Hybridization for Meta-hybrid Just-in-time Compilation Yusuke Izawa Hidehiko Masuhara Tomoyuki Aotani Youyou Cong Meta-interpreter-based language implementation frameworks, such as RPython and Truffle/Graal, are con- venient tool for implementing state-of-the-art virtual machines. Those frameworks are classified into trace- based and method- (or ast-) based strategies. RPython uses a trace-based policy to compile straight execution paths, while Truffle/Graal leverages method invocation to compile entire method bodies. Each approach has its own advantages and disadvantages. The trace-based strategy is good at compiling pro- grams with many branching possibilities and able to reduce the size of compiled code, but it is weak at programs with varying control-flow. The method-based strategy is robust with the latter type of programs but it needs thorough method-inlining management to achieve excellent performance. To take advantage of both strategies, we propose a meta-hybrid compilation technique to integrate trace- and method-based compilations, as well as a proof-of-concept implementation called BacCaml. To achieve this goal, we develop a stack hybridization mechanism which makes it possible to coordinate trace- and method-based meta JIT compilation. In the implementation, we extend RPython's architecture and introduced a special syntax for realizing this system in a single interpreter definition. ing straight execution paths commonly executed 1 Introduction loops. In contrast, Truffle/Graal [16][15] choose Meta-interpreter-based language implementation method-based approach, rewriting abstract-syntax- ast frameworks are getting more and more popular as tree ( ) nodes and applying partial evaluation to they allow language developers to leverage conve- enhance run-time performance. nient components such as a just-in-time (JIT) com- Each strategy has its own pros and cons. The piler and garbage collectors. Many programming trace-based strategy is particularly good at com- languages, such as Python [3][11], Ruby [14][10], piling programs with branching possibilities, which R [9], and Erlang [6], have been implemented with are common in dynamically typed languages. How- language implementation frameworks, and each of ever, it performs poorly in the case of compiling implementations achieves good performance as well Fibonacci like programs [6], where the execution as ahead-of-time compilation. path actually taken at run-time is often different Language mplementation frameworks can be from the one trace for compilation. We call this the classified into two compilation approaches from the path divergence problem. On the other hand, the viewpoint of compilation units. RPython [3][4], method-based strategy is so robust that we can ap- a language implementation framework as part of ply it for a variety of programs. However, it needs the PyPy [3] project, adopts tracing compila- careful function-inlining to achieve excellent run- tion, requiring bytecode interpreters and utiliz- time performance. To take advantage of both compilation strategies, we propose a language implementation framework ∗ This is an unrefereed paper. Copyrights belong to where the language designer writes a single meta- the Author(s). An erlier version of the paper was presented at the MoreVM'19 workshop. interpreter definition; the framework compiles a Yusuke Izawa, Hidehiko Masuhara, Tomoyuki Aotani, part of programs in either compilation strategy, and Youyou Cong, Tokyo Institute of Technology, Dept. the run-time can switch execution between code of Mathematical and Computing Science. fragments compiled by both strategies. The key technique in our proposal is stack hybridization, as by falling back to the interpreter. the two strategies require the meta-interpreter to use stack frames in different ways. 2. 2 Meta-Tracing Compilation In this paper, we describe how to take advantage BacCaml is based on RPython's architecture. of both meta compilation strategies and our design Before describing the implementation details, let choice to implement our meta-hybrid JIT compiler us give an overview of RPython's meta-tracing JIT which we call BacCaml. compilation. 2 Background RPython, a subset of Python, is a tool-chain for Before presenting the implementation of our creating programming languages with a trace-based meta-hybrid compiler, we briefly review tracing and JIT compiler. RPython's trace-based JIT compiler meta-tracing compilation. We also explain the path traces the execution of an user-defined, interpreter divergence problem, a performance degradation in instead of tracing the program that an interpreter tracing JIT compilers. executes. It requires an user to implement a byte- code compiler and an interpreter definition for the 2. 1 Tracing Compilation bytecode. A tracing optimization was firstly investigated by In Figure 1, we show an example of a user-defined Dynamo project [1], and its technique is adopted to interpreter. The example uses two annotations, implement JIT compilers for dynamic languages, jit_merge_point and can_enter_jit. By adding e.g. TraceMonkey JavaScript vm [5] and SPUR, a special annotations to an user-defined interpreter tracing JIT compiler for CIL [2]. as shown in Figure 1, language implementers can vm Generally, tracing JIT compilation is separated make their more efficient. The key annota- into following phases: tions that RPython provides are jit_merge_point • Profiling: The profiler detects commonly exe- and can_enter_jit. We put jit_merge_point cuted loops (hot loop). Typically, this is done at the top of a dispatch loop to indicate it. by counts how many times a backward jump can_enter_jit at the point which a back-edge in- instruction is executed, and if the number is struction can be occurred. Furthermore, we have greater than a threshold, the path is consid- to tell the compiler whether the variables are \red" ered as a hot loop. or \green". \red" means that a variable is rele- • Tracing: The interpreter records all executed vant to the result of a calculation, hence red-colored operations as an intermediate representation variables are recorded in resulting traces. \green" (ir). Therefore function calls in hot loops are variables which are not related to the result, are automatically inlined. executed when tracing the execution. • Code generation: The compiler optimizes In the profiling phase, the profiler monitors the the trace in several ways, e.g. common- program counter at can_enter_jit, and counts subexpression elimination, dead-code elimina- how many times a back-edge instruction (e.g. jump tion, and constant folding, and compiles it into from 204 to 20) is occurred. When the counter gets native code. over the threshold, the JIT compiler goes into the • Execution: After the trace has been compiled tracing phase. Basically, the tracer records or ex- to native code, it is executed when the inter- ecutes instructions the user-defined interpreter ex- preter runs the hot code once again. ecuted. In this tracing phase, only \green" vari- Among all possible branches, only actually exe- ables (such as bytecode, and pc) are executed and cuted one is selected. To make sure that the condi- other \red" variables are recorded. The result- tion of tracing and execution are the same, a special ing traces are optimized and converted into native instruction (guard) is placed at every possible point code. When control reaches again, it goes to the (e.g. if statements) that goes to another direction. compiled code. The guard checks whether the original condition is still valid. If the condition is false, the execution in 2. 3 The Path Divergence Problem the machine code is quit and continues to execute The tracing JIT compilers have weakness in com- piling a particular kind of programs [6], which we int fib(int n) { if (n <= 1) A 1 def push(stack, sp, v): 2 stack[sp] = v return 1; B 3 return sp + 1 } else { 4 int res1 = fib(n ‐ 1); C 5 def pop(stack, sp): 6 v = stack[sp - 1] int res2 = fib(n ‐ 2); D 7 return v, sp - 1 return res1 + res2; } E 8 9 def interp(bytecode): 10 stack = []; sp = 0; pc = 0 11 while True : 12 jit_merge_point( A 13 reds =[ 'stack ', 'sp '], 14 greens =[ 'bytecode ','pc ']) 15 inst = bytecode[pc] B C 16 if inst == ADD : 17 v2, sp = pop(stack, sp) 18 v1, sp = pop(stack, sp) E D 19 sp = push(stack, sp, v1 + v2) 20 elif inst == JUMP_IF: 21 pc += 1 Fig. 2: The Fibonacci function and its control 22 addr = bytecode[pc] flow. 23 if addr < pc: # backward jump 24 can_enter_jit( 25 reds =[ 'stack ', 'sp '], the nodes end with a function call is connected to 26 greens =[ 'bytecode ','pc ']) the entry of the function. Also, the nodes end with 27 pc = addr a return statement is connected to the next basic 28 blocks of its caller, which can be more than one. Tracing compilers rely on the fact that many Fig. 1: An example interpreter definition written program executions contain a subsequence (i.e., a in RPython. sequence of control flow nodes) that appear fre- quently in the entire execution. However, the ex- call the path divergence problem. The problem is ecution of Fibonacci rarely contain such a subse- observed as frequent guard failures (and compila- quence. This is because the branching nodes in the tion of the subsequent traces) when it runs such graph, namely A, B and E in the graph, take one kind of programs. Since it spends most of time for of two following nodes almost the same probability. JIT compilation, the entire execution can be slower As a result, no matter what path the tracing com- than an interpreted execution. piler chooses, the next execution of the compiled Programs that cause the path divergence prob- trace will likely to cause guard failure in its middle lem often take different execution paths when they of execution. are executed. Functions that have multiple non-tail 3 Meta-hybrid JIT Compilation Frame- recursive calls, e.g., Fibonacci, are examples.
Load more

Recommended publications
  • 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]
  • Toward IFVM Virtual Machine: a Model Driven IFML Interpretation
    Toward IFVM Virtual Machine: A Model Driven IFML Interpretation Sara Gotti and Samir Mbarki MISC Laboratory, Faculty of Sciences, Ibn Tofail University, BP 133, Kenitra, Morocco Keywords: Interaction Flow Modelling Language IFML, Model Execution, Unified Modeling Language (UML), IFML Execution, Model Driven Architecture MDA, Bytecode, Virtual Machine, Model Interpretation, Model Compilation, Platform Independent Model PIM, User Interfaces, Front End. Abstract: UML is the first international modeling language standardized since 1997. It aims at providing a standard way to visualize the design of a system, but it can't model the complex design of user interfaces and interactions. However, according to MDA approach, it is necessary to apply the concept of abstract models to user interfaces too. IFML is the OMG adopted (in March 2013) standard Interaction Flow Modeling Language designed for abstractly expressing the content, user interaction and control behaviour of the software applications front-end. IFML is a platform independent language, it has been designed with an executable semantic and it can be mapped easily into executable applications for various platforms and devices. In this article we present an approach to execute the IFML. We introduce a IFVM virtual machine which translate the IFML models into bytecode that will be interpreted by the java virtual machine. 1 INTRODUCTION a fundamental standard fUML (OMG, 2011), which is a subset of UML that contains the most relevant The software development has been affected by the part of class diagrams for modeling the data apparition of the MDA (OMG, 2015) approach. The structure and activity diagrams to specify system trend of the 21st century (BRAMBILLA et al., behavior; it contains all UML elements that are 2014) which has allowed developers to build their helpful for the execution of the models.
    [Show full text]
  • Superoptimization of Webassembly Bytecode
    Superoptimization of WebAssembly Bytecode Javier Cabrera Arteaga Shrinish Donde Jian Gu Orestis Floros [email protected] [email protected] [email protected] [email protected] Lucas Satabin Benoit Baudry Martin Monperrus [email protected] [email protected] [email protected] ABSTRACT 2 BACKGROUND Motivated by the fast adoption of WebAssembly, we propose the 2.1 WebAssembly first functional pipeline to support the superoptimization of Web- WebAssembly is a binary instruction format for a stack-based vir- Assembly bytecode. Our pipeline works over LLVM and Souper. tual machine [17]. As described in the WebAssembly Core Specifica- We evaluate our superoptimization pipeline with 12 programs from tion [7], WebAssembly is a portable, low-level code format designed the Rosetta code project. Our pipeline improves the code section for efficient execution and compact representation. WebAssembly size of 8 out of 12 programs. We discuss the challenges faced in has been first announced publicly in 2015. Since 2017, it has been superoptimization of WebAssembly with two case studies. implemented by four major web browsers (Chrome, Edge, Firefox, and Safari). A paper by Haas et al. [11] formalizes the language and 1 INTRODUCTION its type system, and explains the design rationale. The main goal of WebAssembly is to enable high performance After HTML, CSS, and JavaScript, WebAssembly (WASM) has be- applications on the web. WebAssembly can run as a standalone VM come the fourth standard language for web development [7]. This or in other environments such as Arduino [10]. It is independent new language has been designed to be fast, platform-independent, of any specific hardware or languages and can be compiled for and experiments have shown that WebAssembly can have an over- modern architectures or devices, from a wide variety of high-level head as low as 10% compared to native code [11].
    [Show full text]
  • 1 Lecture 25
    I. Goals of This Lecture Lecture 25 • Beyond static compilation • Example of a complete system Dynamic Compilation • Use of data flow techniques in a new context • Experimental approach I. Motivation & Background II. Overview III. Compilation Policy IV. Partial Method Compilation V. Partial Dead Code Elimination VI. Escape Analysis VII. Results “Partial Method Compilation Using Dynamic Profile Information”, John Whaley, OOPSLA 01 (Slide content courtesy of John Whaley & Monica Lam.) Carnegie Mellon Carnegie Mellon Todd C. Mowry 15-745: Dynamic Compilation 1 15-745: Dynamic Compilation 2 Todd C. Mowry Static/Dynamic High-Level/Binary • Compiler: high-level à binary, static • Binary translator: Binary-binary; mostly dynamic • Interpreter: high-level, emulate, dynamic – Run “as-is” – Software migration • Dynamic compilation: high-level à binary, dynamic (x86 à alpha, sun, transmeta; 68000 à powerPC à x86) – machine-independent, dynamic loading – Virtualization (make hardware virtualizable) – cross-module optimization – Dynamic optimization (Dynamo Rio) – specialize program using runtime information – Security (execute out of code in a cache that is “protected”) • without profiling Carnegie Mellon Carnegie Mellon 15-745: Dynamic Compilation 3 Todd C. Mowry 15-745: Dynamic Compilation 4 Todd C. Mowry 1 Closed-world vs. Open-world II. Overview of Dynamic Compilation • Closed-world assumption (most static compilers) • Interpretation/Compilation policy decisions – all code is available a priori for analysis and compilation. – Choosing what and how to compile • Open-world assumption (most dynamic compilers) • Collecting runtime information – code is not available – Instrumentation – arbitrary code can be loaded at run time. – Sampling • Open-world assumption precludes many optimization opportunities. • Exploiting runtime information – Solution: Optimistically assume the best case, but provide a way out – frequently-executed code paths if necessary.
    [Show full text]
  • Dynamic Extension of Typed Functional Languages
    Dynamic Extension of Typed Functional Languages Don Stewart PhD Dissertation School of Computer Science and Engineering University of New South Wales 2010 Supervisor: Assoc. Prof. Manuel M. T. Chakravarty Co-supervisor: Dr. Gabriele Keller Abstract We present a solution to the problem of dynamic extension in statically typed functional languages with type erasure. The presented solution re- tains the benefits of static checking, including type safety, aggressive op- timizations, and native code compilation of components, while allowing extensibility of programs at runtime. Our approach is based on a framework for dynamic extension in a stat- ically typed setting, combining dynamic linking, runtime type checking, first class modules and code hot swapping. We show that this framework is sufficient to allow a broad class of dynamic extension capabilities in any statically typed functional language with type erasure semantics. Uniquely, we employ the full compile-time type system to perform run- time type checking of dynamic components, and emphasize the use of na- tive code extension to ensure that the performance benefits of static typing are retained in a dynamic environment. We also develop the concept of fully dynamic software architectures, where the static core is minimal and all code is hot swappable. Benefits of the approach include hot swappable code and sophisticated application extension via embedded domain specific languages. We instantiate the concepts of the framework via a full implementation in the Haskell programming language: providing rich mechanisms for dy- namic linking, loading, hot swapping, and runtime type checking in Haskell for the first time. We demonstrate the feasibility of this architecture through a number of novel applications: an extensible text editor; a plugin-based network chat bot; a simulator for polymer chemistry; and xmonad, an ex- tensible window manager.
    [Show full text]
  • Comparative Studies of Programming Languages; Course Lecture Notes
    Comparative Studies of Programming Languages, COMP6411 Lecture Notes, Revision 1.9 Joey Paquet Serguei A. Mokhov (Eds.) August 5, 2010 arXiv:1007.2123v6 [cs.PL] 4 Aug 2010 2 Preface Lecture notes for the Comparative Studies of Programming Languages course, COMP6411, taught at the Department of Computer Science and Software Engineering, Faculty of Engineering and Computer Science, Concordia University, Montreal, QC, Canada. These notes include a compiled book of primarily related articles from the Wikipedia, the Free Encyclopedia [24], as well as Comparative Programming Languages book [7] and other resources, including our own. The original notes were compiled by Dr. Paquet [14] 3 4 Contents 1 Brief History and Genealogy of Programming Languages 7 1.1 Introduction . 7 1.1.1 Subreferences . 7 1.2 History . 7 1.2.1 Pre-computer era . 7 1.2.2 Subreferences . 8 1.2.3 Early computer era . 8 1.2.4 Subreferences . 8 1.2.5 Modern/Structured programming languages . 9 1.3 References . 19 2 Programming Paradigms 21 2.1 Introduction . 21 2.2 History . 21 2.2.1 Low-level: binary, assembly . 21 2.2.2 Procedural programming . 22 2.2.3 Object-oriented programming . 23 2.2.4 Declarative programming . 27 3 Program Evaluation 33 3.1 Program analysis and translation phases . 33 3.1.1 Front end . 33 3.1.2 Back end . 34 3.2 Compilation vs. interpretation . 34 3.2.1 Compilation . 34 3.2.2 Interpretation . 36 3.2.3 Subreferences . 37 3.3 Type System . 38 3.3.1 Type checking . 38 3.4 Memory management .
    [Show full text]
  • Bohm2013.Pdf (3.003Mb)
    This thesis has been submitted in fulfilment of the requirements for a postgraduate degree (e.g. PhD, MPhil, DClinPsychol) at the University of Edinburgh. Please note the following terms and conditions of use: • This work is protected by copyright and other intellectual property rights, which are retained by the thesis author, unless otherwise stated. • A copy can be downloaded for personal non-commercial research or study, without prior permission or charge. • This thesis cannot be reproduced or quoted extensively from without first obtaining permission in writing from the author. • The content must not be changed in any way or sold commercially in any format or medium without the formal permission of the author. • When referring to this work, full bibliographic details including the author, title, awarding institution and date of the thesis must be given. Speeding up Dynamic Compilation Concurrent and Parallel Dynamic Compilation Igor B¨ohm I V N E R U S E I T H Y T O H F G E R D I N B U Doctor of Philosophy Institute of Computing Systems Architecture School of Informatics University of Edinburgh 2013 Abstract The main challenge faced by a dynamic compilation system is to detect and translate frequently executed program regions into highly efficient native code as fast as possible. To efficiently reduce dynamic compilation latency, a dy- namic compilation system must improve its workload throughput, i.e. com- pile more application hotspots per time. As time for dynamic compilation adds to the overall execution time, the dynamic compiler is often decoupled and operates in a separate thread independent from the main execution loop to reduce the overhead of dynamic compilation.
    [Show full text]
  • Language and Compiler Support for Dynamic Code Generation by Massimiliano A
    Language and Compiler Support for Dynamic Code Generation by Massimiliano A. Poletto S.B., Massachusetts Institute of Technology (1995) M.Eng., Massachusetts Institute of Technology (1995) Submitted to the Department of Electrical Engineering and Computer Science in partial fulfillment of the requirements for the degree of Doctor of Philosophy at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY September 1999 © Massachusetts Institute of Technology 1999. All rights reserved. A u th or ............................................................................ Department of Electrical Engineering and Computer Science June 23, 1999 Certified by...............,. ...*V .,., . .* N . .. .*. *.* . -. *.... M. Frans Kaashoek Associate Pro essor of Electrical Engineering and Computer Science Thesis Supervisor A ccepted by ................ ..... ............ ............................. Arthur C. Smith Chairman, Departmental CommitteA on Graduate Students me 2 Language and Compiler Support for Dynamic Code Generation by Massimiliano A. Poletto Submitted to the Department of Electrical Engineering and Computer Science on June 23, 1999, in partial fulfillment of the requirements for the degree of Doctor of Philosophy Abstract Dynamic code generation, also called run-time code generation or dynamic compilation, is the cre- ation of executable code for an application while that application is running. Dynamic compilation can significantly improve the performance of software by giving the compiler access to run-time infor- mation that is not available to a traditional static compiler. A well-designed programming interface to dynamic compilation can also simplify the creation of important classes of computer programs. Until recently, however, no system combined efficient dynamic generation of high-performance code with a powerful and portable language interface. This thesis describes a system that meets these requirements, and discusses several applications of dynamic compilation.
    [Show full text]
  • Coqjvm: an Executable Specification of the Java Virtual Machine Using
    CoqJVM: An Executable Specification of the Java Virtual Machine using Dependent Types Robert Atkey LFCS, School of Informatics, University of Edinburgh Mayfield Rd, Edinburgh EH9 3JZ, UK [email protected] Abstract. We describe an executable specification of the Java Virtual Machine (JVM) within the Coq proof assistant. The principal features of the development are that it is executable, meaning that it can be tested against a real JVM to gain confidence in the correctness of the specification; and that it has been written with heavy use of dependent types, this is both to structure the model in a useful way, and to constrain the model to prevent spurious partiality. We describe the structure of the formalisation and the way in which we have used dependent types. 1 Introduction Large scale formalisations of programming languages and systems in mechanised theorem provers have recently become popular [4–6, 9]. In this paper, we describe a formalisation of the Java virtual machine (JVM) [8] in the Coq proof assistant [11]. The principal features of this formalisation are that it is executable, meaning that a purely functional JVM can be extracted from the Coq development and – with some O’Caml glue code – executed on real Java bytecode output from the Java compiler; and that it is structured using dependent types. The motivation for this development is to act as a basis for certified consumer- side Proof-Carrying Code (PCC) [12]. We aim to prove the soundness of program logics and correctness of proof checkers against the model, and extract the proof checkers to produce certified stand-alone tools.
    [Show full text]
  • Program Dynamic Analysis Overview
    4/14/16 Program Dynamic Analysis Overview • Dynamic Analysis • JVM & Java Bytecode [2] • A Java bytecode engineering library: ASM [1] 2 1 4/14/16 What is dynamic analysis? [3] • The investigation of the properties of a running software system over one or more executions 3 Has anyone done dynamic analysis? [3] • Loggers • Debuggers • Profilers • … 4 2 4/14/16 Why dynamic analysis? [3] • Gap between run-time structure and code structure in OO programs Trying to understand one [structure] from the other is like trying to understand the dynamism of living ecosystems from the static taxonomy of plants and animals, and vice-versa. -- Erich Gamma et al., Design Patterns 5 Why dynamic analysis? • Collect runtime execution information – Resource usage, execution profiles • Program comprehension – Find bugs in applications, identify hotspots • Program transformation – Optimize or obfuscate programs – Insert debugging or monitoring code – Modify program behaviors on the fly 6 3 4/14/16 How to do dynamic analysis? • Instrumentation – Modify code or runtime to monitor specific components in a system and collect data – Instrumentation approaches • Source code modification • Byte code modification • VM modification • Data analysis 7 A Running Example • Method call instrumentation – Given a program’s source code, how do you modify the code to record which method is called by main() in what order? public class Test { public static void main(String[] args) { if (args.length == 0) return; if (args.length % 2 == 0) printEven(); else printOdd(); } public
    [Show full text]
  • A New JIT Compiler in Zing JVM Agenda
    Falcon a new JIT compiler in Zing JVM Agenda • What is Falcon? Why do we need a new compiler? • Why did we decide to use LLVM? • What does it take to make a Java JIT from LLVM? • How does it fit with exiting technology, like ReadyNow? 2 Zing JVM Zing: A better JVM • Commercial server JVM • Key features • C4 GC, ReadyNow!, Falcon 5 What is Falcon? • Top tier JIT compiler in Zing JVM • Replacement for С2 compiler • Based on LLVM 6 Development Timeline PoC GA on by default Apr Dec Apr 2014 2016 2017 Estimated resource investment ~20 man-years (team of 4-6 people) 7 Why do we need a new compiler? • Zing used to have C2 like OpenJDK • C2 is aging poorly — difficult to maintain and evolve • Looking for competitive advantage over competition 8 Alternatives • Writing compiler from scratch? Too hard • Open-source compilers • GCC, Open64, Graal, LLVM… 9 Alternatives • Writing compiler from scratch? Too hard • Open-source compilers short list • Graal vs LLVM 10 “The LLVM Project is a collection of modular and reusable compiler and toolchain technologies” – llvm.org Where LLVM is used? • C/C++/Objective C • Swift • Haskell • Rust • … 12 Who makes LLVM? More than 500 developers 13 LLVM • Started in 2000 • Stable and mature • Proven performance for C/C++ code 14 LLVM IR General-purpose high-level assembler int mul_add(int x, int y, int z) { return x * y + z; } define i32 @mul_add(i32 %x, i32 %y, i32 %z) { entry: %tmp = mul i32 %x, %y %tmp2 = add i32 %tmp, %z ret i32 %tmp2 } 15 Infrastructure provides • Analysis, transformations • LLVM IR => LLVM IR •
    [Show full text]
  • JVM Bytecode
    Michael Rasmussen ZeroTurnaround Intro The JVM as a Stack Machine Bytecode taxonomy Stack manipulation Using locals Control flow Method invocation Tooling Next time public class Test { public static void main(String[] args) { System.out.println("Hello World!"); } } 00000000 ca fe ba be 00 00 00 31 00 22 0a 00 06 00 14 09 |.......1."......| 00000010 00 15 00 16 08 00 17 0a 00 18 00 19 07 00 1a 07 |................| 00000020 00 1b 01 00 06 3c 69 6e 69 74 3e 01 00 03 28 29 |.....<init>...()| 00000030 56 01 00 04 43 6f 64 65 01 00 0f 4c 69 6e 65 4e |V...Code...LineN| 00000040 75 6d 62 65 72 54 61 62 6c 65 01 00 12 4c 6f 63 |umberTable...Loc| 00000050 61 6c 56 61 72 69 61 62 6c 65 54 61 62 6c 65 01 |alVariableTable.| 00000060 00 04 74 68 69 73 01 00 06 4c 54 65 73 74 3b 01 |..this...LTest;.| 00000070 00 04 6d 61 69 6e 01 00 16 28 5b 4c 6a 61 76 61 |..main...([Ljava| 00000080 2f 6c 61 6e 67 2f 53 74 72 69 6e 67 3b 29 56 01 |/lang/String;)V.| 00000090 00 04 61 72 67 73 01 00 13 5b 4c 6a 61 76 61 2f |..args...[Ljava/| 000000a0 6c 61 6e 67 2f 53 74 72 69 6e 67 3b 01 00 0a 53 |lang/String;...S| . 000001d0 b6 00 04 b1 00 00 00 02 00 0a 00 00 00 0a 00 02 |................| 000001e0 00 00 00 04 00 08 00 05 00 0b 00 00 00 0c 00 01 |................| 000001f0 00 00 00 09 00 10 00 11 00 00 00 01 00 12 00 00 |................| 00000200 00 02 00 13 |....| Compiled from "Test.java” public class Test { public Test(); Code: 0: aload_0 1: invokespecial #1 // Method java/lang/Object."<init>":()V 4: return public static void main(java.lang.String[]); Code: 0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream; 3: ldc #3 // String Hello World! 5: invokevirtual #4 // Method java/io/PrintStream.println: // (Ljava/lang/String;)V 8: return } Welcome my son Welcome to the machine Where have you been? It's alright we know where you've been.
    [Show full text]