Ambiente de Execução de Alta Densidade para Computação em Nuvem

This project proposes Shell, a new sandbox that results from virtualizing language runtimes. Shell offers a virtualized language runtime as containers and VMs offer a virtualized instance of an OS and physical hardware, respectively. Shell is meant to be a key step forward in the evolution of language runtimes to support the demands of tomorrow’s cloud computing. It drives extreme scalability and elasticity by allowing a single runtime to handle any number of applications with minimal overhead and is projected to achieve memory footprint overheads under 1 MB and initialization times under 1 ms, two orders of magnitude better when compared to state-of-the-art virtualization technology (VMs and containers) [10]. To successfully virtualize language runtimes, this project will address three questions (which correspond to three independent work packages): How to enforce memory isolation between multiple Shells? Memory isolation has been traditionally offered by Memory Management Units (MMUs) which allow OSs to switch between address spaces when different processes execute. However, switching address spaces has been shown to be slow due to the Translation Look-aside Buffer flushes and to lead to high memory footprint which comes as a consequence of using different address spaces. There are also solutions based on Software-Fault Isolation (SFI) in which multiple sandboxes co-execute in the same address space (examples include WebAssembly and Memory Isolates). However, this alternative is deemed unsafe as it solely relies on software for isolation. In this project we aim to pursue a third approach that combines traditional SFI with recently proposed hardware extensions to enforce memory isolation in a single address space. We plan to study the applicability of Intel Memory Protection Keys (for Intel processors), ARM Memory Permission Overlays, and ARM Capability Hardware Enhanced RISC Instructions (CHERI); How to enforce OS resource isolation (e.g., file system, access to networking)? VMs offer OS resource isolation by simply running different OS instances, one per VM. This, however, leads to long VM initialization times and high memory footprint as a result of redundancy. Containers on the other hand use OS primitives that lock each container on a different view of the entire system. These primitives, Namespaces in Linux, can be used to isolate OS resources but come at a high startup latency. To support Shell creation under 1 ms we plan to explore: i) how namespaces can be efficiently cached for future use, and ii) if Shell instances can be lazily moved into different namespaces as resources are requested by the application; How to reuse JIT-compiled code? Reusing JIT-compiled code is of paramount importance due to the profiling and compilation overhead. Since JIT compilers are crucial to support high-level languages, state-of-the-art works propose reusing compiled code by taking advantage of Checkpoint/Restore (C/R) either at the VM level or at the container level [4]. We plan to continue previous work by planning to investigate how C/R tools can be adapted to work at the sandbox level (Shell) instead of VM/container level. As a final objective, Shell should be designed with no assumptions on the language runtime, nor target language. Instead, it should be proposed as a general framework for virtualizing language runtimes.