Programmation par aspect et Machine Virtuelle Virtuelle

Programmation par aspect et Machine Virtuelle Virtuelle Bertil Folliot LIP6 / CNRS, Université Pierre et Marie Curie, Paris 6 INRIA Regal Bertil.Folliot@lip6.fr JTE ASF-SIGOPS, AOP, Lille, septembre 2005 Ce projet est, ou a été, partiellement financé par les projets RNRT Phenix (99S0361), France Télécom R&D ISA (001B117), GEMPLUS, le LIP6 (PLERS 2000), la communauté européenne (IST COACH-34445) et Web2Grid. Bertil.Folliot@lip6.fr http://vvm.lip6.fr AOP & MVV - 1 Plan 1. Problématique autour des environnements d'exécution 2. Objectifs de la Machine Virtuelle Virtuelle 3. Programmation de la MVV 4. MVV & AOP : exemples d applications 5. Conclusion AOP & MVV - 2

Introduction : besoins de la flexibilité logicielle Multitudes de normes et de standards (de facto ou de jure) ODP, CORBA, CCM, JAVA, EJB, DCOM,.NET, JINI, BLUETOOTH Technologies logicielles rigides (!) Multiplication des cas particuliers Qualité de Service, tolérance aux fautes, performances, taille Multiplication des «domaines informatiques» travail coopératif, télétravail, multimédia, mondes virtuels, réseaux actifs, domotique, informatique «embarqué», GRID Évolution rapide du matériel loi de Moore valide pour les X prochaines années (?) PC, PDA, Cartes à puces, étiquettes électroniques AOP & MVV - 3 Où est le problème? La recherche en système/intergiciel n est plus d en re-faire trop long, trop coûteux, trop rigide + cf. évolution du matériel Les besoins des «domaines informatiques» (applications émergentes) changent les objectifs des logiciels (performances) : répartition géographique des utilisateurs et des ressource, forte contrainte de sécurité (données sensibles, copyright, droits d'accès), modèles de données complexes et réparties, configurations dynamiques de partenaires hétérogènes, conditions d interactions inconnues lors de la conception. AOP & MVV - 4

Pourquoi est-ce un problème? Chaque «domaine» à un environnement d exécution adapté (langage, API, OS ou «colle OS») ex1 : impression - postscript / dvips - «imprimer» / printcap - sél. d imprimante ex2 : réseaux actifs - langage dédié (bytecode) / send-receive / OS? Le nombre de domaines est en forte augmentation fonction du matériel (PDA ) ou du logiciel - QdS (réalité virtuelle) Les besoins changent/évoluent au cours de l exécution cf. Internet (latence, bande passante, «hot spot of the week») spécifications initiales (matériel, QdS) NOUVEAUX langages et/ou API et/ou OS MAIS figé et/ou non interopérable et/ou difficile à réutiliser AOP & MVV - 5 Un exemple : les machines virtuelles Machines virtuelles classiques (ex : Java VM) En utilisation croissante pour résoudre les problèmes systèmes Applications portables, code compact sure, (un peu) spécialisable Chargement de bytecode, interprétation, JIT-C MyAppli main() { execution engine object - loader MV classique AOP & MVV - 6

Contre-exemple : les machines virtuelles Le «domaine» de la JVM suppose : beaucoup de mémoire, pas (peu) d accès à l OS, pas (beaucoup) de QdS f(matériel)? carte à puce (JavaCard), téléphone (KVM) f(propriétés)? persistance (Pjama), temps réel (RT-Java) f(temps qui passe)? gestion de crise (FT-Java) Les MVs sont une étape dans la bonne direction, MAIS : peu flexible (nouveau domaine => nouveau langage + nouvelle MV) peu adaptable difficilement interopérable AOP & MVV - 7 Alors quelle approche? Ne pas travailler pour le cas général (en général ça fonctionne bien), mais travailler sur le minimum (KISS) 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éale (adaptée) à un problème particulier AOP & MVV - 8

Solution : les MVVs Virtualiser la machine virtuelle = MVV MVV = [MV]V est une plate-forme d'exécution (MV) dans laquelle on construit son environnement d'exécution (appelé MVlet) : langage, API, modules systèmes Une MVlet correspond à un domaine d'application Spécification exécutable de haut-niveau (écrite en langage VVM) Chargeable/déchargeable dynamiquement Vérification des propriétés Un mécanisme d'exécution au sein de la MVV pour toutes les MVlets Environnement d exécution «actif» AOP & MVV - 9 Architecture de la MVV My appli (type SuperVM) (something to do) My SuperVMlet Application loader (define-instruction ()) (define-object ()) (define-syntax ()) (define-primitives ()) (define-loader ()) (use-os-module ()) VMlet loader "SuperVM" "SuperVM" "SuperVM" Execution engine - Virtual processor Object memory VVM µ-vm {OS,ø} {CPU, memory, I/O} AOP & MVV - 10

Pourquoi l approche MVV résout le problème Adaptabilité/spécialisation du support d'exécution aux divers domaines - ou aux applications elles-mêmes (OS + langage) Flexibilité/extensibilité pour ajouter/modifier des fonctionnalités, en fonction de l'application, de son utilisation ou des évolutions matérielles (configuration/re-configuration + déploiement) Interopérabilité pour l'échange de données entre applications, pour la mobilité (code et/ou donnée) et pour favoriser la réutilisation Prise en compte de la logique métier (expérience PLERS) tout ne peut/ne doit être adaptable/flexible/interopérable AOP & MVV - 11 Programmation des VMlets Langage interne de la VVM [Scheme] Programmation de VMlets de langages de programmation : C (un lexeur/parseur) Java (un lexeur/parseur + une VM Java complète) [JnJVM] autres Programmation de VMlets de langages de programmation spécialisées (DSL) : Compilateur : multimédia [Compilette] Système : temps -réel [VMlet-BOSSA] Applications : réseaux actifs [ANTSlet/PLANet], cache Web [CNN], monitoring [C/SPAN] Méthodologies : VVM & AOP? AOP & MVV - 12

AOP (en bref) Séparation des préoccupations, modularisation, inversion de contrôle, adaptation Point de jonction + Tisseur (Langage de programmation + moteur statique/dynamique) AspectJ, AspectWerkz, Jac, Steamloom VMlet : généralisation de l AOP (ou le contraire)? Point de jonction : l adresse (l objet, la méthode, la classe, la bibliothèque, etc.) Tisseur manuel Aspects multiples Vérification AOP & MVV - 13 VMlets et aspects Compilation (non?) Système (oui!) : temps-réel, etc. Applications? AOP & MVV - 14

Système : VMlet-Bossa Application (pid 13024) VMlet-Bossa (use-os-module bossa ) Politique Linux Politique EDF (root) Loader : XWin VM temps-réel VVM µ-vm Linux {OS,ø} 2.4 (bossa) {CPU, memory, I/O} scheduler Bossa AOP & MVV - 15 Applications? Exemple d un cache Web Cache local de documents distants Trois politiques: remplacement, coopération, cohérence Pour le remplacement: pas d algorithme optimal algo. de système de gestion de fichiers (FIFO, LRU, LFU ) algo. spécifique au Web (Hybrid, LNC-R-W3, MIX, Greedy Dual Size ) Réalisation d une WebCacheLet - Avantages : Une nouvelle politique s'écrit (en Scheme) en ~10 minutes Se charge et se compile dans la MVV en 50 ms Se change (si elle était déjà compilée) en 0,57 ms Benchmarks : ajout/changement de politique, observation à la volée, mode trace L'API du cache Web EST le cache lui-même Est-ce un aspect? AOP & MVV - 16

VMlet Web cache filter Nouvelle politique : [E. Casalicchio and M. Colajanni, Scalable Web Cluster with Static and Dynamic Contents, Proceedings of the IEEE International Conference on Cluster Computing (CLUSTER 2000), Chemnitz, Germany, December 2000.] ;; VMlet new replacement policy (define filterpolicy (lambda (doc) (if (= 0 (:system.strncmp (:httphdr.typemime doc) "text" 4)) (GDS-cost doc) (SIZE-cost doc) ) ) ) AOP & MVV - 17 Tissage? VMlet de reconfiguration ;; VMlet reconfiguration function (define xevalswitch (lambda (newpolicy size) (let [(head 0) (oldcost 0)] (set! currentreview newpolicy) (set! head (getworst repository size)) (while head(set! oldcost (:docs.cost (:cell.data head))) (currentreview (:cell.data head)) (:httpr.updt repository (:cell.data head) oldcost) (set! head (:cell.next head)))))) ;; VMlet reconfiguration command (xevalswitch filterpolicy (/ (httpr.size repository) 5)) AOP & MVV - 18

Cache Web auto-adaptable VMlet cache Web flexible [CNN] + PANDORA (plate-forme de monitoring auto-adaptable) (+ qq. lignes de codes C d intégrations PANDORA/VVM) = Cache web flexible auto-adaptable [C/SPAN] AOP & MVV - 19 VVM et AOP : synthèse Les VMlets sont des aspects (qui sont des VMlets qui ) Le tisseur est une VMlet (qui est un aspect qui ), mais écrit par ~le même programmeur Le tissage et les aspects sont gérés par la VVM VMlet de Tissage d aspect? Langage d entrée : XML [VMletXML] (stage DEA 2003) Tisseur : VMletJAP (stage DEA 2005) Tisseur dynamique d aspects avec les performances d un tissage statique et qui reste flexible/adaptable/interopérable AOP & MVV - 20

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, Xen) / Aperios : un unique langage dédié, difficile à manipuler (et à imposer) Systèmes embarqués MultOS, Windows CE, SCP, µclinux, KVM (Sun - réutilisation de CCG-LIP6) : différences avec la problématique? 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 AOP & MVV - 21 Conclusion : vers un environnement d'exécution actif Mise à jour de la plate-forme à la volée Délocalisation des fonctionnalités Interopérabilité extrême é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. AOP & MVV - 22

Questions? AOP & MVV - 23 Références - VVM http://vvm.lip6.fr/ VVM : [Bertil Folliot, Ian Piumarta, Fabio Riccardi. Virtual Virtual Machine. Cabernet Radical Workshop, Crète, Septembre 1997.] [Ian Piumarta, Bertil Folliot, Lionel Seinturier, Carine Baillarguet. Highly configurable operating systems: the VVM approach. Proc. of ECOOP'2000 Workshop on Object Orientation and Operating Systems, Cannes, Juin 2000.] [Bertil Folliot, Ian Piumarta, Lionel Seinturier, Carine Baillarguet, Christian Khoury, Arthur Léger, Fréderic Ogel. Beyond flexibility and reflection: the virtual virtual machine approach. NATO Advanced Research Workshop, Environments, Tools and Applications for Cluster Computing. LNCS 2326, Springer-Verlag, pp. 17-26, 2002.] [Frédéric Ogel, Bertil Folliot, Ian Piumarta. On Reflexive and Dynamically Adaptable Environments for Distributed Computing. Proc. 3rd International Workshop on Distributed Auto-adaptive and Reconfigurable Systems, ICDCS 2003, IEEE, Providence, Rhode Island, Mai 2003.] YNVM : [Ian Piumarta, Frederic Ogel, Bertil Folliot. YNVM: dynamic compilation in support of software evolution. In Proc. Ingeneering Complex Object Oriented System for Evolution, OOPSLA, Tampa Bay, Floride, Octobre 2001.] VVM et ORB dynamique : [Bertil Folliot, Ian Piumarta, Lionel Seinturier. Middleware and Reflective Features of the Virtual Virtual Machine. Proc. of Workshop on Reflective Middleware, IFIP/ACM Middleware 2000, New York, USA, pp. 8-9, Avril 2000.] [Frédéric Ogel, Bertil Folliot, Ian Piumarta. On Reflexive and Dynamically Adaptable Environments for Distributed Computing. In Proc. 3rd International Workshop on Distributed Auto-adaptive and Reconfigurable Systems, ICDCS 2003, IEEE, Providence, Rhode Island, Mai 2003.] AOP & MVV - 24

Références : VMlets Réseaux actifs : [Christian Khoury, Bertil Folliot, Ian Piumarta. AAN: A Highly Reflective Active Network. In Proc. 20 st IASTED Applied Informatics Conference, Innsbruck, Autriche, Février 2002.] Web caching : [Ian Piumarta, Frederic Ogel, Carine Baillarguet, Bertil Folliot. Applying the VVM kernel to Flexible Web Caches. Proc IEEE Workshop on Hot Topics in Operating Systems, HOTOS-VII, Schloss Elmau, RFA, pp. 155, mai 2001.] extended version in research report INRIA. Corot : [Arthur Léger, Bertil Folliot, Damien Cailliau. Platform for Software Reconfiguration in Embedded Systems. Proc. of European Research Seminar on Advances in Distributed Systems, Bertinoro, Italie, Mai 2001.] [Damien Cailliau, Arthur Léger, Olivier Marin, Bertil Folliot. A joint middleware/configuration language approach for space embedded software update.proc. DAta Systems In Aerospace, DASIA 2001, (CSA, CNES, ESA), Nice, Mai 2001.] [Damien Cailliau, Arthur Léger, Bertil Folliot. Using high level configuration language for safer space software update. Proc. International Astronautical Congress de l'iaf, Toulouse, Octobre 2001.] Documents actifs : [Gaël Thomas, Bertil Folliot, Ian Piumarta. Documents actifs Journées des Jeunes Chercheurs en Systèmes, Chapitre français de l ACM-SIGOPS, Hammamet, Tunisie, pp. 441-447, Avril 2002.] AOP & MVV - 25