COOLER: COmpOsing LanguagE Runtimes

传统上，大多数软件项目都是使用一种编程语言来处理的。然而，随着我们对软件的野心越来越大，这是越来越不自然的：没有一种语言，无论多么“好”，是适合所有事情的。越来越多的不同社区已经创建或采用了非传统语言——通常，尽管并不总是，在领域特定语言（dsl）的旗帜下——以满足他们的特定需求。考虑一个大型组织。后台软件可采用SQL和Java；其桌面软件c#；网站后端PHP，前端Javascript和HTML5；可以使用R创建报表；一些部门可能会使用Python或Haskell来开发软件原型。尽管组织使用不同的语言，但每种语言都必须在自己的筒仓中执行。我们目前很少有技术允许使用多种语言编写单个运行程序。在Cooler项目中，我们将其称为“运行时组合”问题：语言如何能够彼此直接执行、交换数据、相互调用、相互优化等等？组合语言运行时的主要现有技术是将组合中的所有语言翻译成一种基本语言，最常见的是一个“大型”虚拟机（vm）的字节码——Java的HotSpot或HotSpot。净的CLR。虽然这种方法在某些情况下效果很好，但它有两个主要问题。首先，VM将有意地针对特定的语言族，并且可能不提供该语言族之外的语言所需的原语。例如，HotSpot不支持尾部递归或延续，排除了许多高级语言。其次，VM公开的原语可能不能有效地执行程序。例如，在HotSpot上运行的动态类型语言比它们看似不那么复杂的“自制”vm运行得慢。Cooler项目采用了一种新的方法来解决组合问题。它假设元跟踪将允许任意语言运行时的有效组合。元跟踪是最近开发的一种技术，它使用定制的即时（JIT）编译器创建高效的虚拟机。首先，语言设计者为他们选择的语言编写一个解释器。当解释器执行用户的程序时，代码中的热路径被记录（“跟踪”）、优化并转换为机器码；随后的调用使用快速的机器码而不是缓慢的解释器。元跟踪不同于部分求值：它记录解释器对特定用户程序执行的实际操作。元跟踪是一项令人兴奋的新技术，原因有三。首先，它带来了快速的虚拟机：PyPy虚拟机（Python的完全兼容的重新实现）比CPython（基于c的Python虚拟机）和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.