EPSRC logo

Details of Grant 

EPSRC Reference: EP/K01790X/1
Title: COOLER: COmpOsing LanguagE Runtimes
Principal Investigator: Tratt, Professor L
Other Investigators:
Researcher Co-Investigators:
Project Partners:
Oracle Corporation
Department: Informatics
Organisation: Kings College London
Scheme: Standard Research
Starts: 03 June 2013 Ends: 02 August 2017 Value (£): 618,883
EPSRC Research Topic Classifications:
Fundamentals of Computing
EPSRC Industrial Sector Classifications:
Information Technologies
Related Grants:
Panel History:
Panel DatePanel NameOutcome
21 Nov 2012 EPSRC ICT Responsive Mode - Nov 2012 Announced
Summary on Grant Application Form
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.
Key Findings
This information can now be found on Gateway to Research (GtR) http://gtr.rcuk.ac.uk
Potential use in non-academic contexts
This information can now be found on Gateway to Research (GtR) http://gtr.rcuk.ac.uk
Impacts
Description This information can now be found on Gateway to Research (GtR) http://gtr.rcuk.ac.uk
Summary
Date Materialised
Sectors submitted by the Researcher
This information can now be found on Gateway to Research (GtR) http://gtr.rcuk.ac.uk
Project URL:  
Further Information:  
Organisation Website: