Valid XHTML 1.1! Valid CSS!

VVM's Overview

Laboratoire Informatique de Paris 6 Systèmes Répartis et Coopératifs Inria

VVM is a joint project between LIP6/CNRS (SRC team) and INRIA (Regal team).

Why VVMs ?

Nowadays systems and architectures are complex, respond badly to many "emerging" application needs, and are not easily specialisable to support a given application or architecture. This leads to a proliferation of non-reusable "ad-hoc" solutions and place stringent requirements on developers. Our response to this challenge is a systematic approach for software configuration based on a multi-language, hardware independent execution platform, called the Virtual Virtual Machine (VVM) [FOL98]. The VVM offers both a programming and an execution environment allowing: i) to adapt the execution environment (language + system) to a given domain (for instance: smart card, mobile phone, personal computer or satellite), ii) to be extensible by changing on the fly the execution environment (adding new functionalities, algorithms, or upgrading the hardware), iii) to promote interoperability between applications. Adaptability, extensibility and interoperability offer new solutions to current emerging applications (embedded systems, virtual world, active networks, active spaces and so on). In the following we briefly present the current state of the VVM project, the Recursive Virtual Machine, the first results obtained in the domain of active networks, and the ongoing work for building a reconfigurable execution environment on board of the french satellite Corot.

For what for ?

Emerging applications are coming from the wider acceptance of distributed computing and the ubiquitous use of "intelligent" devices (mobile telephone, smart card, embedded systems on so on). This kind of applications is characterized by dynamic configurations of heterogeneous interacting parties. This lead to an increasing number and complexity of system components - for data manipulation and storage, communication, fault tolerance, mobility, security and so on. We believe that current standard solution (as CORBA, Java or DCOM) while looking as mature technology respond badly to many emerging application needs and will only introduce more problems later on. Comparizons with other existing approaches like flexible operating systems, specializable virtual machine, meta-object protocol, and language ineroperability are not described here. As an attempt to answer to the emerging application challenge, we propose a systematic approach for software configuration. It is based on a multi-language, hardware independent execution platform, called the Virtual Virtual Machine (VVM). The Virtual Virtual Machine is a programming and execution environment that is dynamically extensible and tailored to application needs [PIU00]. To help understand the main principles behind the VVM, let's compare with a classical virtual machine (like the SUN Java Virtual Machine [LIN99]). A virtual machine approach is a step in the right direction and VMs in general are in increasing use to solve operating system problems. Thanks to the bytecode representation, applications are portable and compact, and the instruction set is dynamically specializable. However the Java VM is still far too rigid. It corresponds to an application domain where there is a high amount of available main memory, limited access to the underlying operating system, and no quality of service. This is why, new virtual machines have to be implemented when the application domain does not correspond to these requirements (for a given architecture, as a smartcard, or for a given software requirement as fault tolerance).

Brief architectural description

Instead of implementing a new virtual machine for each application domain, the goal of the VVM is to "virtualize" the virtual machine. New specifications of VM adapted for an application domain are loaded on demands in the VVM. These specifications are called VMlets. A VMlet contains in a high level language the complete description of the execution environment (bytecodes, syntax, operating system services, API and so on). The VMlets are themselves encoded in compact bytecoded programs. They are not juste declarative, but imperative and may alter their own execution environment. For instance, according to the environment where they are loaded they may restrain the visibility of given functionalities. Thus, the VVM can be seen as a VM, executing VMlets, that transform the VM to the one contained in the VMlet (see Figure 1). Bytecoded applications can then be run on this specialized VM.

VVM Architecture
Figure 1 &ndash VVM architecture

It is important to notice that after executing the VMlet, the VVM, becomes the VM described in the VMlet. Thus, there is a single level of bytecode interpretation. As a result the performance after loading a VMlet in the VVM should be quite similar to the corresponding hand-coded VM. The main advantages are the reduced complexity to program a VMlet and its associated applications, and the extensibility of the VVM allowing to change it on the fly, possibly fundamentally altering its functionality. Moreover the VVM can support several VMlets thus offering a multi-functionality VM and promoting interoperability between applications.

Last modification on: Thu Apr 12 2001 - 13:46:46 +0200