Draining the Swamp: Micro Virtual Machines as Solid Foundation for Language Development

Many of today\u27s programming languages are broken. Poor performance, lack of features and hard-to-reason-about semantics can cost dearly in software maintenance and inefficient execution. The problem is only getting worse with programming languages proliferating and hardware becoming more complicated. An important reason for this brokenness is that much of language design is implementation-driven. The difficulties in implementation and insufficient understanding of concepts bake bad designs into the language itself. Concurrency, architectural details and garbage collection are three fundamental concerns that contribute much to the complexities of implementing managed languages. We propose the micro virtual machine, a thin abstraction designed specifically to relieve implementers of managed languages of the most fundamental implementation challenges that currently impede good design. The micro virtual machine targets abstractions over memory (garbage collection), architecture (compiler backend), and concurrency. We motivate the micro virtual machine and give an account of the design and initial experience of a concrete instance, which we call Mu, built over a two year period. Our goal is to remove an important barrier to performant and semantically sound managed language design and implementation

Recycling the Optimized Machine Codes Generated by JavaScript Engine

학위논문 (석사)-- 서울대학교 대학원 공과대학 전기·정보공학부, 2017. 8. 문수묵.자바스크립트의 역할이 계속해서 증대되고 있으며, 자바스크립트 엔진의 성능이 중요한 이슈가 되고 있다. 본 논문은 자바스크립트 엔진의 성능을 향상하기 위한 방법으로 다단계(multi-tiered) JIT 컴파일 엔진에서 최적화 JIT 컴파일러가 생성하는 기계어 코드를 재활용하는 방식을 제안한다. 이 방식에서는 최적화 JIT 컴파일러가 생성하는 기계어 코드를 파일에 저장하였다가 다음 프로그램 수행에서 이를 재사용한다. 그리하여 엔진에서 컴파일 오버헤드를 제거하고 시작부터 양질의 코드를 사용하게 만든다. 기계어 코드를 재사용하기 위해서는 코드 내의 포인터들을 현재 수행에 맞게 패치 해주어야 하는데, 이를 위하여 기계어 코드와 함께 코드 내의 포인터 위치 및 포인터가 가리키는 객체의 정체를 같이 저장하는 테이블을 생성, 저장한다. 최적화 JIT 컴파일러에서는 베이스라인 JIT 에서와는 달리 완성된 테이블을 만들기 위해 최적화 과정 중에서 파생적으로 생성되는 포인터와 프로파일에 의해 고정 생성되는 포인터들까지 찾아서 처리해야 한다. 전자는 최적화 과정을 같이 따라가면서, 후자는 컴파일러가 포인터를 고정 생성하지 못하도록 바꾸어 처리한다. 이를 실제 자바스크립트 엔진 중의 하나인 JavaScriptCore 엔진에서 적용한 결과, 사용자가 선택적으로 이득이 되는 기계어 코드들만 재사용 했을 시 최대 29%, 평균 11%의 성능 향상이 있었다.제 1 장 서 론 1 제 2 장 자바스크립트 엔진의 구조 3 제 1 절 자바스크립트 엔진 3 제 2 절 최적화 JIT 컴파일러와 Profile 5 제 3 절 WebKit의 JavaScriptCore 7 제 3 장 최적화된 기계어 코드의 재활용 8 제 1 절 개요 8 제 2 절 포인터 패칭 9 제 3 절 최적화 과정과 포인터 생성 10 제 4 절 Profile과 포인터 생성 12 제 5 절 선택적인 재활용 14 제 4 장 실험 결과 및 분석 16 제 1 절 실행 환경 16 제 2 절 실험 결과 16 제 3 절 관찰 결과 17 제 5 장 결론 및 향후 연구 18 참고문헌 19 Abstract 20Maste

HW-SW co-design techniques for modern programming languages

Modern programming languages raise the level of abstraction, hide the details of computer systems from programmers, and provide many convenient features. Such strong abstraction from the details of computer systems with runtime support of many convenient features increases the productivity of programmers. Such benefits, however, come with performance overheads. First, many of modern programming languages use a dynamic type system which incurs overheads of profiling program execution and generating specialized codes in the middle of execution. Second, such specialized codes constantly add overheads of dynamic type checks. Third, most of modern programming languages use automatic memory management which incurs memory overheads due to metadata and delayed reclamation as well as execution time overheads due to garbage collection operations. This thesis makes three contributions to address the overheads of modern programming languages. First, it describes the enhancements to the compiler of dynamic scripting languages necessary to enable sharing of compilation results across executions. These compilers have been developed with little consideration for reusing optimization efforts across executions since it is considered difficult due to dynamic nature of the languages. As a first step toward enabling the reuse of compilation results of dynamic scripting languages, it focuses on inline caching (IC) which is one of the fundamental optimization techniques for dynamic type systems. Second, it describes a HW-SW co-design technique to further improve IC operations. While the first proposal focuses on expensive IC miss handling during JavaScript initialization, the second proposal accelerates IC hit operations to improve the overall performance. Lastly, it describes how to exploit common sharing patterns of programs to reduce overheads of reference counting for garbage collection. It minimizes atomic operations in reference counting by biasing each object to a specific thread

어플리케이션 다운로딩 시스템을 위한 클라이언트 선행 컴파일러

학위논문 (박사)-- 서울대학교 대학원 : 전기·컴퓨터공학부, 2014. 8. 문수묵.어플리케이션(앱)을 다운로드 받아서 수행하는 시스템은 DTV나 스마트폰처럼 대중적으로 사용되고 있다. 앱을 다운받아서 사용하는 시스템들은 가상 머신을 주류로 사용하고 있다. 가상 머신의 가장 큰 문제점은 인터프리터를 통한 수행에 의한 느린 성능이며, 이 성능의 향상을 위해 주로 사용되는 기술이 적시 컴파일러이다. 적시 컴파일러는 다운받은 앱의 수행 중에 동적으로 머신 코드로 번역하여 사용하는 기법으로, 동적 컴파일레이션 오버헤드를 가지게 된다. 우리는 이 동적 컴파일레이션 오버헤드를 제거하여 성능을 향상시키는 클라이언트 선행 컴파일러를 제안하였다. 클라이언트 선행 컴파일러는 적시 컴파일러가 생성하는 머신 코드를 앱의 종료될 때 지우지 않고 파일형태로 스토리지에 저장하여 이후에 앱이 다시 수행될 때 저장한 머신 코드를 재활용하여 사용함으로써 런타임 컴파일레이션 오버헤드를 제거하게 된다. 저장한 머신 코드를 재활용할 때 머신 코드에 인코딩된 주소값들은 유효하지 않기 때문에 가상 머신의 현재 값에 맞추어 변경해주는 작업이 필요하다. 이 작업은 주소 재배치이다. 주소 재배치는 저장된 머신 코드만으로 수행할 수가 없기 때문에 추가적인 정보를 머신 코드를 저장하는 과정에서 생성하여 파일에 함께 저장해 주어야 한다. 자바의 상수 풀 해석은 주소 재배치 작업을 어렵게 한다. 우리는 이에 대한 해결책을 만들었다. 주소 재배치를 위한 정보들을 저장하기위해 영구 메모를 많이 사용하는 것도 문제가 된다. 따라서 우리는 주소 재배치 정보를 머신 코드 상에 인코딩하고 압축하여 저장하는 방법을 제안했다. 우리의 클라이언트 선행 컴파일러 기법은 오라클사의 CDC 가상머신 참조구현인 CVM에 구현하였다. 우리의 클라이언트 선행 컴파일러는 벤치마크의 성능을 약 12% 향상시켰다. 또한 우리는 클라이언트 선행 컴파일러 기법을 실제로 판매하는 DTV환경에 구축하여 실제 방송국이 사용하는 어플리케이션을 수행해 보았다. 우리의 클라이언트 선행 컴파일러 방식은 사용자의 실제 환경에서 33%의 좋은 성능 향상을 얻었다. 자바스크립트 가상머신인 구글사의 V8 가상머신은 인터프리터 수행없이 적시 컴파일러만을 사용하고 있다. 우리는 V8 가상 머신에 클라이언트 선행 컴파일러는 적용하였지만, 실제 성능 향상을 얻어내지는 못했다. 이것은 V8 가상 머신의 특징인 내부 객체의 적극적인 사용에 의한 결과이다. 내부 객체는 컴파일러가 생성하여 컴파일러 과정에서 사용되며, 자바스크립트 프로그램에서도 접근하여 사용하게 된다. V8 가상 머신의 컴포넌트들은 대부분 내부 객체로 생성되어, 다른 종류의 가상 머신에 비해서 상당히 많은 내부 객체를 생성하고 있다. V8의 적시 컴파일러가 생성하는 머신 코드에서는 이 내부 객체를 직접 접근하여 사용하게 되어, 클라이언트 선행 컴파일러에 의해 어플리케이션이 수행될 때마다 이 내부 객체는 항상 필요하기 때문에 클라이언트 선행 컴파일러는 내부 객체를 재생성해야만 한다. V8 적시 컴파일러의 런타임 컴파일레이션 오버헤드의 대부분이 내부 객체를 생성하는 오버헤드이기 때문에, 우리의 클라이언트 선행 컴파일러는 이 환경에서 충분한 성능 향상을 얻을 수 없었다.App-downloading systems like DTV and smart phone are popularly used. Virtual machine is mainstream for those systems. One critical problem of app-downloading systems is performance because app is executed by interpreter. A popular solution for improving performance is Just-In-Time Compiler (JITC). JITC compiles to machine code at runtime. So, JITC suffers from runtime compilation overhead. We suggested client Ahead-Of-Time Compiler(c-AOTC) which improves the performance by removing runtime compilation overhead. c-AOTC saves machine code of method generated by JITC in persistent storage and reuses it in next runs. The machine code of a method translated by JITC is cached on a persistent memory of the device, and when the method is invoked again in a later run of the program, the machine code is loaded and executed directly without any translation overhead. One major issue in c-AOTC is relocation because some of the address constants embedded in the cached machine code are not correct when the machine code is loaded and used in a different runthose addresses should be corrected before they are used. Constant pool resolution complicates the relocation problem, and we propose our solutions. The persistent memory overhead for saving the relocation information is also an issue, and we propose a technique to encode the relocation information and compress the machine code efficiently. We developed a c-AOTC on Oracles CDC VM, and evaluation results indicate that c-AOTC can improve the performance as much as an average of 12% for benchmarks. And we adopted c-AOTC approach to commercial DTV platform and test the real xlet applications of commercial broadcasting stations. c-AOTC got average 33% performance improvement on the real xlet application test. V8 JavaScript VM does not use interpreter. Apps are executed only by JITC. We adopted c-AOTC to V8 VM. But we cannot get any good performance result because of V8 VMs characteristics. V8 VM components are generated as internal objects. Internal objects are used for compiling and running of JavaScript program. The machine code of V8 VM addresses internal objects which are different for each run. Because internal objects be　accessed in each run, c-AOTC　must recreate those objects. Because most of compilation overhead of V8 VM is internal object creation overhead, c-AOTC　does not get enough improvements.Chapter 1 Introduction 1 Chatper 2 client-AOTC Approach 4 Chatper 3 Java Virtual Machine and Our JITC 9 3.1 Overview of JVM and the Bytecode 9 3.2 Our JITC on the CVM 14 Chatper 4 Design and Implementation of c-AOTC on JVM 16 4.1 Architecutre of the c-AOTC 16 4.2 Relocation 19 4.2.1 Translated Code Which Needs Relocation 19 4.2.2 Relocation Information and Relocation Process 22 4.2.3 Relocation for Inlined Methods 24 4.3 Reducing the Size of .aotc Files 25 4.3.1 Encoding Relocation Information 25 4.3.2 Machine Code Compression 27 4.3.3 Structure of the .aotc File 27 Chatper 5 c-AOTC for DTV JVM platform 29 5.1 DTV software platform 30 5.2 c-AOTC on the DTV 32 5.2.1 Design of c-AOTC on DTV 32 5.2.2 Relocation Problem 35 5.2.3 Example of Relocation 39 5.2.3.1 Relocation Example of JVM c-AOTC 39 5.2.3.3 Relocation Example of DTV c-AOTC 41 Chatper 6 c-AOTC for JavaScript VM 44 6.1 V8 JavaScript VM 44 6.2 Issue and Solution of c-AOTC on V8 JavaScript VM 46 Chatper 7 Experimental Results 51 7.1 Experimental Environment of JVM 51 7.2 Performance Impact of c-AOTC 53 7.3 Space Overhead of c-AOTC 55 7.4 Reducing Number of c-AOTC Methods 60 7.5 c-AOTC with new hot-spot detection heuristics 63 7.5.1 Performance Impact of c-AOTC with new hot-spotdetection heuristics 63 7.5.2 Space Overhead of c-AOTC with new hot-spot detection heuristics 67 7.6 c-AOTC of DTV JVM platform 70 7.6.1 Performance result of DTV platform 70 7.6.2 Analysis of JITCed method of DTV platform 72 7.6.3 Space overhead of DTV platform 74 7.6.4 c-AOTC overhead of DTV platform 75 7.6.5 c-AOTC performance using different xlets c-AOTC file in DTV platform 76 7.7 c-AOTC of V8 JavaScript engine 79 7.7.1 Compilation overhead on V8 JavaScript VM 79 7.7.2 Performance result on V8 JavaScript VM 81 7.7.3 Comparison with c-AOTC of JavaScriptCore VM 83 Chatper 8 Related Work 86 Chatper 9 Conclusion 89 Bibliography 91 초록 99Docto

Differential Fuzzing the WebAssembly

WebAssembly, colloquially known as Wasm, is a specification for an intermediate representation that is suitable for the web environment, particularly in the client-side. It provides a machine abstraction and hardware-agnostic instruction sets, where a high-level programming language can target the compilation to the Wasm instead of specific hardware architecture. The JavaScript engine implements the Wasm specification and recompiles the Wasm instruction to the target machine instruction where the program is executed. Technically, Wasm is similar to a popular virtual machine bytecode, such as Java Virtual Machine (JVM) or Microsoft Intermediate Language (MSIL). There are two major implementations of Wasm, correlated with the two most popular web browsers in the market. These two are the V8 engine by Chromium project and the SpiderMonkey engine by Mozilla. Wasm does not mandate a specific implementation over its specification. Therefore, both engines may employ different mechanisms to apply the specification. These different implementations may open a research question: are both engines implementing the Wasm specification equally? In this thesis, we are going to explore the internal implementation of the JavaScript engine in regards to the Wasm specification. We experimented using a differential fuzzing technique, in which we test two JavaScript engines with a randomly generated Wasm program and compares its behavior. We executed the experiment to identify any anomalous behavior, which then we analyzed and identified the root cause of the different behavior. This thesis covers the WebAssembly specification extensively. It discusses several foundational knowledge about the specification that is currently lacking in references. This thesis also presents the instrumentation made to the JavaScript engine to perform the experiment, which can be a foundation to perform a similar experiment. Finally, this thesis analyzes the identified anomaly found in the experiment through reverse engineering techniques, such as static and dynamic analysis, combined with white-box analysis to the JavaScript engine source code. In this experiment, we discovered a different behavior of the JavaScript engine that is observable from the perspective of the Wasm program. We created a proof-of-concept to demonstrate the different behavior that can be executed in the recent web browser up to the writing of this thesis. This experiment also evaluated the implementation of both JavaScript engine on the Wasm specification to conclude that both engines implement the specification faithfully

Simple optimizing JIT compilation of higher-order dynamic programming languages

Implémenter efficacement les langages de programmation dynamiques demande beaucoup d’effort de développement. Les compilateurs ne cessent de devenir de plus en plus complexes. Aujourd’hui, ils incluent souvent une phase d’interprétation, plusieurs phases de compilation, plusieurs représentations intermédiaires et des analyses de code. Toutes ces techniques permettent d’implémenter efficacement un langage de programmation dynamique, mais leur mise en oeuvre est difficile dans un contexte où les ressources de développement sont limitées. Nous proposons une nouvelle approche et de nouvelles techniques dynamiques permettant de développer des compilateurs performants pour les langages dynamiques avec de relativement bonnes performances et un faible effort de développement. Nous présentons une approche simple de compilation à la volée qui permet d’implémenter un langage en une seule phase de compilation, sans transformation vers des représentations intermédiaires. Nous expliquons comment le versionnement de blocs de base, une technique de compilation existante, peut être étendue, sans effort de développement significatif, pour fonctionner interprocéduralement avec les langages de programmation d’ordre supérieur, permettant d’appliquer des optimisations interprocédurales sur ces langages. Nous expliquons également comment le versionnement de blocs de base permet de supprimer certaines opérations utilisées pour implémenter les langages dynamiques et qui impactent les performances comme les vérifications de type. Nous expliquons aussi comment les compilateurs peuvent exploiter les représentations dynamiques des valeurs par Tagging et NaN-boxing pour optimiser le code généré avec peu d’effort de développement. Nous présentons également notre expérience de développement d’un compilateur à la volée pour le langage de programmation Scheme, pour montrer que ces techniques permettent effectivement de construire un compilateur avec un effort moins important que les compilateurs actuels et qu’elles permettent de générer du code efficace, qui rivalise avec les meilleures implémentations du langage Scheme.Efficiently implementing dynamic programming languages requires a significant development effort. Over the years, compilers have become more complex. Today, they typically include an interpretation phase, several compilation phases, several intermediate representations and code analyses. These techniques allow efficiently implementing these programming languages but are difficult to implement in contexts in which development resources are limited. We propose a new approach and new techniques to build optimizing just-in-time compilers for dynamic languages with relatively good performance and low development effort. We present a simple just-in-time compilation approach to implement a language with a single compilation phase, without the need to use code transformations to intermediate representations. We explain how basic block versioning, an existing compilation technique, can be extended without significant development effort, to work interprocedurally with higherorder programming languages allowing interprocedural optimizations on these languages. We also explain how basic block versioning allows removing operations used to implement dynamic languages that degrade performance, such as type checks, and how compilers can use Tagging and NaN-boxing to optimize the generated code with low development effort. We present our experience of building a JIT compiler using these techniques for the Scheme programming language to show that they indeed allow building compilers with less development effort than other implementations and that they allow generating efficient code that competes with current mature implementations of the Scheme language

Reaching across - managing variants of one application on multiple platforms

The number of platforms to support in today's software projects are many and there are a wide range of differences to consider. There are tons of programming languages on the market and each platform, both mobile and desktop, have different preferences on how to develop applications. This do often result in multiple applications, similar to the end user but different to the developers. The same functionality has to be developed and maintained in multiple versions of the application in different ways. To solve these issues there is a need to think of the applications and platform in a new way. They have to be unified and commonalities has to be found or made. New application structures and tools are also needed to keep the platforms in sync. When developing those concepts each platform’s flexibility must be protected. Each platform has it’s own advantages and features like a GPS and camera and they have to be available to build a competitive product. This report concludes that web technology such as HTML5, JavaScript and CSS is a promising way to introduce common parts in the application. This helps to manage the platforms in one way and reduces the differences. To retain the platform specifics, language bridges are used to directly communicate with the native platform from the web parts. This enables the full strength of each platform and makes the solution a fully featured competitor to native applications