Langage machine | EPFL Graph Search

Le langage machine, ou code machine, est la suite de bits qui est interprétée par le processeur d'un ordinateur exécutant un programme informatique. C'est le langage natif d'un processeur, c'est-à-dire le seul qu'il puisse traiter. Il est composé d'instructions et de données à traiter codées en binaire. Chaque processeur possède un langage machine. Si un processeur A est capable d'exécuter toutes les instructions du processeur B, on dit que A est compatible avec B. L'inverse n'est pas forcément vrai : A peut avoir des instructions supplémentaires que B ne connaît pas. Le code machine est aujourd'hui généré automatiquement, généralement par le compilateur d'un langage de programmation ou par l'intermédiaire d'un bytecode. Instructions du langage Instruction informatique Les « mots » d'un langage machine sont appelés instructions. Chacune d'elles déclenche une commande de la part du processeur (par exemple additionner deux valeurs, copier une valeur, etc.). Un processeur à

Just-in-time performance without warm-up

Denys Shabalin

Scala has been developed as a language that deeply integrates with the Java ecosystem. It offers seamless interoperability with existing Java libraries. Since the Scala compiler targets Java bytecode, Scala programs have access to high-performance runtimes including the HotSpot virtual machine. HotSpot provides impressive performance results achieved via just-in-time compilation. It starts program execution in interpreter mode, collecting profile feedback about called methods. This information allows HotSpot to identify hot spots in the program, which are then compiled on the fly to native code. This compilation scheme enables high peak performance at the cost of warmup time required to collect the profile data and perform just-in-time compilation. This is a good example of the traditional tradeoff between ahead-of-time (AOT) and just-in-time (JIT) compilation. With AOT, compilers have less information, but the runtime story is reasonably straightforward. With JIT, compilers have more information, which enables advanced optimizations, but the runtime story becomes complicated. In this dissertation, we present the design and implementation of Scala Native, an optimizing compiler for Scala. With Scala Native, Scala programs are compiled ahead of time, which avoids runtime compilation and enables instant startup times. On the other hand, Scala Native is able to match and supersede the peak performance of HotSpot on our benchmarks. In addition to that, Scala Native is a general-purpose Scala compiler - programs compiled by Scala Native closely match the behavior of programs compiled by the Scala compiler. First, we introduce NIR, an intermediate representation designed with ahead-of-time compilation in mind. NIR represents programs in the single-static assignment form and has support for object-oriented features such as virtual dispatch and multiple inheritance. This representation is a key enabler of our compilation and optimization pipeline. Secondly, we present Interflow, a link-time optimizer that takes advantage of the closed-world assumption to optimize the whole program at once. Our optimizer employs a number of techniques including partial evaluation, allocation sinking, and method duplication. The combination of these techniques allows Scala Native to outperform HotSpot on the majority of our benchmarks. Finally, we describe how to improve runtime performance even further based on profile feedback. We propose a technique that splits methods apart isolating key hot paths that are then optimized more aggressively than the cold parts of the program. This provides a further performance advantage over HotSpot.

EPFL2020

Reengineering Standard Java Runtime Systems through Dynamic Bytecode Instrumentation

Philippe Moret

Java bytecode instrumentation is a widely used technique, especially for profiling purposes. In order to ensure the instrumentation of all classes in the system, including dynamically generated or downloaded code, instrumentation has to be performed at runtime. The standard JDK offers some mechanisms for dynamic instrumentation, which however either require the use of native code or impose severe restrictions on the instrumentation of certain core classes of the JDK. These limitations prevent several instrumentation techniques that are important for efficient, calling context-sensitive profiling. In this paper we present a generic bytecode instrumentation framework that goes beyond these restrictions and enables the customized, dynamic instrumentation of all classes in pure Java. Our framework addresses important issues, such as bootstrapping an instrumented JDK, as well as avoiding measurement perturbations due to dynamic instrumentation or execution of instrumentation code. We validated and evaluated our framework using an instrumentation for exact profiling which generates complete calling context trees of various platform-independent dynamic metrics.

2007

A Quantitative Evaluation of the Contribution of Native Code to Java Workloads

Philippe Moret

Many performance analysis tools for Java focus on tracking executed bytecodes, but provide little support in determining the specific contribution of native code libraries. This paper introduces and assesses a portable approach for characterizing the amount of native code executed by Java applications. A profiling agent based on the JVM Tool Interface (JVMTI) accurately keeps track of all runtime transitions between bytecode and native code. It relies on a combination of JVMTI events, Java Native Interface (JNI) function interception, bytecode instrumentation, and hardware performance counters.

2006

Just-in-time performance without warm-up

Denys Shabalin

EPFL2020