As software becomes increasingly complex and difficult to analyze, it is more and more common for developers to use high-level, type-safe, object-oriented (OO) programming languages and to architect systems that comprise multiple components. Different components are often implemented in different programming languages. In state-of-the-art multicomponent, multi-language systems, cross-component communication relies on remote procedure calls (RPC) and message passing. As components are increasingly co-located on the same physical machine to ensure high utilization of multi-core systems, there is a growing potential for using shared memory for cross-language cross-runtime communication. We present the design and implementation of Co-Located Runtime Sharing (CoLoRS), a system that enables crosslanguage,

Communications programming, involving complex message exchanges over multiple transports, is an omnipresent element in modern distributed applications. Existing engineering solutions however have considerable limitations: there is no portability across differing transports. Programming abstractions for communication are typically provided through low-level APIs, bound to specific transports or application domains, without offering either type or protocol safety. This paper proposes an extensible Java-based language and runtime framework which enables safe and efficient virtualisation of communications programming across heterogeneous transports. Application programmers describe communications in terms of high-level, structured sessions, without concern for underlying transport mechanisms. After type-checking, the compiler generates a transport-independent intermediate form, which can be efficiently executed by the runtime across different transports whilst ensuring communication safety. Through portable, abstract low-level communication instructions defined by the Abstract Transport, a new transport can quickly and seamlessly integrate with existing session services. A case for transport independence is made using concrete applications from widely different domains, including parallel algorithms, a Web-based application server, and Internet chat. The benchmark results show this framework imparts significant gains in portability, safety and productivity, as well as efficient utilisation of individual transports through type-directed optimisation. 1.

We present GC-as-a-Service (GaS), a cross-runtime, crosslanguage garbage collection (GC) library that can be used to simplify the implementation of runtime systems, and that exploits available multicore technologies. GaS decouples GC from other runtime components and exposes a fine-grain API for use by GC-cooperative runtimes of different programming languages for heap memory management. GaS provides concurrent, on-the-fly GC and avoids moving objects for use as a precise or conservative collector. We integrate GaS within production-quality runtime systems for Python and Java. Our experimental evaluation shows that using GaS as an alternative to tightly integrated GC introduces modest overhead and that GaS reduces pause times significantly for Python and Java programs.

Past research in virtualisation technology has mainly focused on increasing isolation of co-resident virtual machines. At the same time network intensive applications, such as web services or database applications are being consolidated onto a single physical platform. The isolation properties of virtualisation, however, demand a strict separation of the shared resources. Co-resident virtual machines are therefore forced to fallback to inefficient network emulation for communication. Many inter virtual machine communication methods proposed recently, introduced shared memory, customised libraries or APIs. This is not only unpractical but can also undermine a system’s integrity; moreover transparency and live migration is commonly neglected. Therefore in this paper we discuss the challenges and requirements for inter virtual machine communication and examine available solutions proposed by academia and industry. We also discuss how the current evolution of virtualisation and modern CPUs pose new challenges for inter virtual machine communication. Finally, we consider the possibility of utilising previously unused CPU capabilities to accommodate an inter virtual machine communication mechanism. 1