VVM is a joint project between LIP6/CNRS (SRC team) and INRIA (Regal team).
As a first step to the (long) way to the VVM, we realized the Recursive Virtual Machine. The RVM is able to modify its own instruction and primitive sets at runtime. It's a Lisp like interactive language that has been implemented on top of UNIX for several architectures (Pentium, Sparc and PowerPC). By adding or changing instructions sets on the fly, the RVM allows to reconfigure itself to a VM adapted to a given application domain. For now, this application domain should be able to run on top of Unix (we are working on a RVM version based on the OSKit [FOR97] that will allow the RVM to adapt the operating system itself). Compared to an operating system the RVM looks like a mono-user, mono-application environment. The difficult problems of interoperability between VMlets and the security/verification of the specifications contained in a VMlets are still open. Though quite limited, the RVM has been used to experiment with the programming of VMlets. For this work, we have considered the application domain of active networks. To simplify, there are two kinds of packets in an active network: data and code packets. Code packets are executed on routers and can manipulate the packets (change, suppress or add new data packets). Among the dozens active network protocols we quoted two: PLAN [HIC98] and ANTS [WET98]. In PLAN, each packet contains both the code and the data. In ANTS, there is an initialization phase where the code packets are sent to all the routers. Then, data packets use a code identifier to indicate which code has to handle the packet. Each of these two protocols has advantages and disadvantages - not described here.
To solve with the RVM the active network application domain, we have to define the appropriate VMlet: language, operating system services, API. As language, we didn't consider proposing a dedicated language, and used the Lisp like internal language of the RVM. As system services, we reused the socket primitives of the underlying UNIX operating system ( select(), send(), receive() and so on). As API, we have imitated the API of PLAN (onremote to send an active packet, getttl to get the time to live of the packet and so on). Then, by loading this VMlet, the RVM transforms itself to an active network router that understands PLAN packet. The main lesson of this exercise is that the VMlet-PLAN is two orders of magnitude smaller than the original implementation (counted as byte of source code). We have implemented an other VMlets that mimics the API of ANTS, and we obtain similar result. We are in the process of making the two VMlets coexist in order to experiment with interoperability between active networks and to select the most appropriate protocol for each packet (i.e. to choose between memory used and communication bandwidth). The next step will be to build an "active active network", where traditional "active networks" contains VMlets packet.
In response to the exponential growth of Internet traffic, web proxy caches are deployed everywhere. Nonetheless, their efficiency relies on a large number of intrinsically dynamic parameters, most of which can not be predicted statically. Furthermore, in order to react to changing execution conditions — such as network resources, user behavior or flash crowds, or to update the web proxy with new protocols, services or even algorithms — the entire system must be dynamically adapted.
Our response to this problem is a self-adapting Web proxy cache, C/SPAN, that applies administrative strategies to adapt itself and react to external events. Because it is completely flexible, even these adaptation policies can be dynamically adapted.
Remember that this work has been done using a limited prototype. Adding change to the underlying operating system, or allowing several VMlets to run simultaneously (next version of the RVM), will allow exploring much more complex application domains. A target one, that is a generalization of the active network work, is what we call "active application". As in active network a packet contains code to manipulate the data, in active application, an application contains code to manipulate the application (both code and data).
A challenging execution environment is a reconfigurable software environment on board satellite. This application domain represents an extreme case of embedded systems, posing severe constraints as, memory footprint and communications optimizations, real time, limited processing power, fault tolerance and so on. In collaboration with the Space Research department of Paris Observatory we are creating a dedicated version of the VVM to the french satellite Corot (to be launched in 2005). The scientific mission running on this satellite is based on theoretical models that will only be tested during the flight. Thus, the software on board of the satellite should be adaptable according to the physical conditions observed (see [CAI99] for details on the needed reconfigurations). Our work is to provide the configuration language (called Corot Configuration Language, CCL) and the associated interpreter, allowing the scientific station on the ground to describe optimized and proved versions of new configurations to be uploaded on the satellite. This is one of the first attempt to propose a systematic and provable way to reconfigure very constrained embedded system. CCL and its interpreter are very tight to the environmental conditions of Corot (2 to 4 non interactive communications by day, 140kbits/day of information in the uplink, limited memory, CPU utilisation for reconfiguration limited to 10% and so on). The next step will be to generalize this work for reconfiguration in severely constrained embedded systems, making the environmental conditions themselves adaptable.
YNVM is a recursive acronym for Ynvm's Not a Virtual Machine.
JNJVM is a recursive acronym for Jnjvm's Not a Java Virtual Machine.
The JNJVM is an execution environment for Active Java Applications.
DVVM is an acronym for Distributed Virtual Virtual Machine.
YNVM was improved to offer a reflexif system of naming. We argue that a system is handled via the names of its inner components. DVVM introduces the mount command to attach the component names of other DVVMs and serialize functions and a transfer protocol to share components between DVVMs.
YNVM is a reflective environment, it can reason about itself and adapt itself. DVVM can reason about, and adapt, another DVVM as it handles itself.
Last modification on: Thu Apr 12 2001 - 13:48:21 +0200