La machine virtuelle virtuelle utopie et/ou réalité ? Bertil Folliot Ian Piumarta Lionel Seinturier Carine Baillarguet LIP6 /CNRS - thème SRC, Université Paris 6 INRIA Rocquencourt - projet SOR Bertil.Folliot@lip6.fr Lionel.Seinturier@lip6.fr www-sor.inria.fr/~vvm Projet financé par un RNRT (Phenix 99S0361) une CTI FT (ISA 001B117) une ACI jeunes chercheurs (AProDis) un projet LIP6 (PLERS) But de la MVV : proposer et mettre en œuvre un système d'exploitation et un environnement d'exécution qui contrairement aux systèmes et aux environnements habituels soit flexible, extensible et adaptable aux besoins des applications.

Besoins des applications modernes Environnement d'exécution actif Adaptabilité/spécialisation : OS + langage Flexibilité/extensibilité pour ajouter/modifier des fonctionnalités, en fonction de l'application, de son utilisation ou des évolutions matérielles Écrire efficacement des applications est difficile : un domaine particulier nécessite un environnement approprié (OS+langage). La plupart des OS actuels sont rigides ==> la complexité explose Les environnements d'exécution actuels sont peu appropriés aux applications modernes : Travail coopératif, systèmes embarqués, cartes à puce, téléphonie mobile, multimédia, mondes virtuels, réseaux actifs. Répartition géographique des utilisateurs et des ressources, forte contrainte de sécurité (données sensibles, copyright, droits d'accès), modèles de données complexes, configurations dynamiques de partenaires hétérogènes Le matériel évolue rapidement : les performances augmentent, les prix et la taille diminuent et les OS "classiques" n'ont pas le temps de suivre. Mise à jour de la plate-forme à la volée Délocalisation des fonctionnalités Échanges de données et de fonctionnalités (même pour des application écrites dans différents langages) - applets, agents Le (difficile) travail de construire l'environnement d'exécution, n'est fait qu'une fois pour un domaine (optimisation agressive, spécialisation dynamique) Facilité de programmation (langage de haut niveau et services systèmes dédiés au problème à résoudre), réduction du temps de mise sur le marché, pas de langage de programmation unique

Machines virtuelles Machines virtuelles “classiques” (ex : Java VM) En utilisation croissante pour résoudre les problèmes systèmes Applications portables, compactes, “sures”, (un peu) spécialisables Chargement de bytecode, interprétation, JIT MV classique MyAppli main() {} moteur d'exécution chargeur d'objets Machines virtuelles (contre-exemple - inconvénients) f(matériel) : carte à puce f(propriétés) : temps réél f(temps qui passe) : gestion de crise Généralisation : 1) spécialisation statique - fs() connue à l'avance 2) spécialisation dynamique fd() connue à l'exécution` 1) long, couteux à développer - rigide une fois déployée 2) ne fonctionne que si fs(fd()) ==> idem 1 MAIS peu flexible (nouveau domaine => nouveau langage + nouvelle MV) pas adaptable (évolution du langage) pas intéropérable

Objectifs Construire une plate-forme d'exécution (minimale) dans laquelle chaque expert informatique d'un domaine construit son environnement d'exécution (OS, API, langage) sur lequel les programmeurs développent les solutions Adaptation et flexibilité et interopérabilité Quel est le problème ? Ne pas travailler pour le cas général (en général ça fonctionne bien) mais travailler sur le minimum Extraire la complexité de la solution (système) vers une représentation de haut niveau Notre solution : Virtualiser la machine virtuelle = MVV coupe transversale depuis l’application jusqu’au matériel ou… comment construire l’environnement d’exécution “idéal” adapté à un problème particulier Environnement d'exécution actif Mise à jour de la plate-forme à la volée Délocalisation des fonctionnalités Échanges de données et de fonctionnalités (même pour des application écrites dans différents langages) - applets, agents Le (difficile) travail de construire l'environnement d'exécution, n'est fait qu'une fois pour un domaine (optimisation agressive, spécialisation dynamique) Facilité de programmation (langage de haut niveau et services systèmes dédiés au problème à résoudre), réduction du temps de mise sur le marché, pas de langage de programmation unique

Machine Virtuelle Virtuelle MVV = une plate-forme d'exécution (MV) dans laquelle on construit son environnement d'exécution (appelé MVlet) : langage, API, modules systèmes, … type: maVMlet main() { ... } monAppli code natif interpréteur optimiseur générateur de code myPush { ... } getList { ... } def-ins myPush def-prim getList maVMlet Une MVlet correspond à un domaine d'application Spécification exécutable de haut-niveau Chargeable/déchargeable dynamiquement Vérification des propriétés Un seul mécanisme d'exécution au sein de la MVV pour toutes les MVlets Favorise l'interopérabilité et la réutilisation de code existant Partage les ressources physiques entre les MVlets Permet d'incorporer des optimisations agressives La MVV ne résoud pas le probème applicatif en lui-même ressource minimale mémoire, E/S, CPU MV d'environnement système MV d'environnement applicatif

MVV & AOP Programmation par aspects (AOP) améliorer et augmenter la modularité des applications gérer le code enchevêtré Un aspect une unité de décomposition transverse [conception] aux fonctionalités de l'application une structure logicielle [implantation] Transversalité des aspects inhérente dans les applications complexes traduit un besoin d'intégration de l'application dans son environnement ne peut pas forcément être traitée par les approches habituelles code enchevêtré résultant de l'ajout et de la cohabitation de nombreuses fonctionnalités exemple : audit, exceptions, optimisation, comm distante, synchro, persistance des données le code devient redondant (le même fragment se retrouve en de multiples endroits) la compréhension globale de l'application devient + difficile les modificiations deviennent dures : retrouver toutes les occurrences, être sûr de les modifier de façon cohérente, veiller à ne pas les modifier accidentellement en modifiant une autre fonctionnalité => coûts de développement et de maintenance importants ... transpa - convergence langage/système - ex à base de librairies, aspects langages : gestion d'exception, optimisation

MVV & AOP Principe de la programmation par aspects aspect Application tresseur d'aspects Application augmentée par les aspects compilation/ interprétation application méta modèle points de jonction Le méta-modèle comprend la définition de points de jonction. Ce sont les endroits dans le code de l'application où les aspects vont pouvoir être appliqués. Exemple : appel de méthode, réception d'un appel de méthode, levée d'une exception, tout autre élément syntaxique ou sémantique du langage, voire même des patterns soit de code (par ex pour l'optimisation, inlining de boucle, dérécursivation), soit d'interaction (traitement sur une chaîne d'appel) Le tresseur d'aspects définit quand et comment les aspects vont être exécutés en fonction des points de jonction définis.

dynamique d'applications MVV & AOP Niveau langage Niveau environnement d'exécution méta-modèle tresseur accès réflexif au code d'une application reconfiguration dynamique d'applications niveau langage : ce qui est nécessaire pour l'AOP niveau environnement d'exécution : ce que permet la MVV Gains escomptés performances (recompilation dynamique) facilité d'écriture du tresseur (MVlet)

MVV & Distribution des connaissances Notion d'information active La MVV sert de base pour concevoir un environnement d'exécution actif pour la mobilité et le partage d'information Ajout dynamique de nouvelles connaissances (sous forme de règles, programmes, ...) pour traiter l'information

Réalisation RVM et µ-MV Machines virtuelles à la Scheme Disponible (900Ko) sous licence GPL Générateur dynamique de code de MV Chargement dynamique de bibliothèque système Applications Réseaux actifs : PLANlet et ANTSlet Satellite PLERS reconfiguration logiciel pour le satellite COROT Par rapport à l'existant Machines virtuelles spécialisables génération d'une MV en fonction des performances, de la taille du code, du domaine, etc. (JavaCard, PLAN, Harissa) peu/pas extensible, le même travail doit être refait pour chaque domaine Système d'exploitation flexible / MOP changement de fonctionnalités et d'interfaces (SPIN, ExoKernel, Fluke) / Aperios : un unique langage dédié Interopérabilité des langages exécution de plusieurs langages (Java, Smalltalk, VisualBasic pour la Machine Virtuelle Universelle d'IBM) : basé sur une MV existante (Smalltalk), pas extensible