COOLER: COmpOsing LanguagE Runtimes

传统上，大多数软件项目都是使用单一编程语言来处理的。然而，随着我们对软件的雄心壮志越来越大，这变得越来越不自然：没有一种语言，无论多么“好”，都不能完全适合一切。越来越多的不同社区创建或采用非传统语言--通常(但并非总是)打着领域特定语言(DSL)的旗号--以满足其特定需求。它的后端软件可以使用SQL和Java；它的桌面软件C#；它的网站后端PHP和前端Java脚本和HTML5；报告可能使用R创建；一些部门可能使用Python或Haskell制作软件原型。尽管该组织使用不同的语言，但每种语言都必须在自己的竖井中执行。我们目前几乎没有允许使用多种语言编写单个运行程序的技术。在Cooler项目中，我们将此称为“运行时组合”问题：语言如何彼此直接并行执行、交换数据、相互调用、相互优化等等？组成语言运行时的主要现有技术是将组合中的所有语言翻译成一种基本语言，最常见的是将“大”虚拟机(VM)之一的字节代码--Java的热点或.NET的CLR。虽然这在某些情况下效果很好，但它有两个主要问题。首先，VM将故意针对特定的语言系列，并且可能不提供该系列之外的语言所需的原语。例如，HotSpot不支持尾递归或延续，不支持许多高级语言。其次，VM公开的原语可能不允许有效地执行程序。例如，在HotSpot上运行的动态类型语言运行速度比它们看起来不那么复杂的“home BREW”VM慢得多。Cooler项目采用了一种新的方法来解决组合问题。它假设元跟踪将允许有效地组合任意语言运行时。元跟踪是最近开发的一种技术，它使用定制的即时(JIT)编译器创建高效的VM。首先，语言设计者为他们选择的语言编写一个翻译器。当该解释器执行用户程序时，代码中的热路径将被记录(“跟踪”)、优化并转换为机器码；随后的调用将使用该快速机器码而不是速度较慢的解释器。元跟踪不同于部分求值：它记录解释器对特定用户程序执行的实际操作。元跟踪是一项令人兴奋的新技术，原因有三。首先，它带来了快速的VM：PyPy VM(一个完全兼容的Python重新实现)比CPython(基于C的PythonVM)和Jython(JVM上的Python)快5倍以上。其次，它需要的资源很少：Converge语言的元跟踪实现在不到3个人的月内完成，运行速度比CPython和Jython更快。第三，因为用户自己编写解释器，所以不存在对任何特定语言家族的偏见。Cooler项目最初将设计专门为元跟踪设计的第一种语言(而不是像现有系统那样，重用不合适的现有语言)。这将使我们能够探索语言运行时组合的各个方面。首先，跨运行时共享：不同的范例(例如命令式和功能性)如何交换数据和行为？第二，优化：如何优化以多种范式编写的程序(空间和时间)？最后，我们将通过已知的难题来探讨该方法的局限性：跨运行时垃圾回收；并发性；以及在多大程度上可以组合不是为组合而设计的运行时。最终，该项目将允许用户以目前不可行的方式将运行时和程序组合在一起。

Traditionally, most software projects have been tackled using a single programming language. However, as our ambitions for software grow, this is increasingly unnatural: no single language, no matter how "good", is well-suited to everything. Increasingly, different communities have created or adopted non-traditional languages - often, though not always, under the banner of Domain Specific Languages (DSLs) - to satisfy their specific needs.Consider a large organisation. Its back-end software may utilise SQL and Java; its desktop software C#; its website back-end PHP and the front-end Javascript and HTML5; reports may be created using R; and some divisions may prototype software with Python or Haskell. Though the organisation makes use of different languages, each must execute in its own silo. We currently have few techniques to allow a single running program to be written using multiple languages. In the Cooler project, we call this the "runtime composition" problem: how can languages execute directly alongside each other, exchange data, call each other, optimise with respect to each other, etc.?The chief existing technique for composing language runtimes is to translate all languages in the composition down to a base language, most commonly the byte code for one of the "big" Virtual Machines (VMs) - Java's HotSpot or .NET's CLR. Though this works well in some cases, it has two major problems. Firstly, a VM will intentionally target a specific family of languages, and may not provide the primitives needed by languages outside that family. HotSpot, for example, does not support tail recursion or continuations, excluding many advanced languages. Secondly, the primitives that a VM exposes may not allow efficient execution of programs. For example, dynamically typed languages running on HotSpot run slower than their seemingly much less sophisticated "home brew" VMs.The Cooler project takes a new approach to the composition problem. It hypothesizes that meta-tracing will allow the efficient composition of arbitrary language runtimes. Meta-tracing is a recently developed technique that creates efficient VMs with custom Just-in-Time (JIT) compilers. Firstly, language designers write an interpreter for their chosen language. When that interpreter executes a user's program, hot paths in the code are recorded ("traced"), optimised, and converted into machine code; subsequent calls then use that fast machine code rather than the slow interpreter. Meta-tracing is distinct from partial evaluation: it records actual actions executed by the interpreter on a specific user program. Meta-tracing is an exciting new technique for three reasons. Firstly, it leads to fast VMs: the PyPy VM (a fully compatible reimplementation of Python) is over 5 times faster than CPython (the C-based Python VM) and Jython (Python on the JVM). Secondly, it requires few resources: a meta-tracing implementation of the Converge language was completed in less than 3 person months, and runs faster than CPython and Jython. Third, because the user writes the interpreter themselves, there is no bias to any particular family of languages.The Cooler project will initially design the first language specifically designed for meta-tracing (rather than, as existing systems, reusing an unsuitable existing language). This will enable the exploration of various aspects of language runtime composition. First, cross-runtime sharing: how can different paradigms (e.g. imperative and functional) exchange data and behaviour? Second, optimisation: how can programs written in multiple paradigms be optimised (space and time)? Finally, the limits of the approach will be explored through known hard problems: cross-runtime garbage collection; concurrency; and to what extent runtimes not designed for composition can be composed. Ultimately, the project will allow users to compose together runtimes and programs in ways that are currently unfeasible.