AOP & MVV - 1

Programmation par aspectet

Machine Virtuelle Virtuelle

Bertil Folliot

LIP6 / CNRS, Université Pierre et Marie Curie, Paris 6INRIA 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 - 2

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 - 3

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 - 4

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 - 5

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 - 6

Un exemple :les machines virtuelles

Machines virtuelles “classiques” (ex : Java VM)En utilisation croissante pour résoudre les problèmes systèmesApplications “portables”, code compact“sure”, (un peu) spécialisable

Chargement de bytecode, interprétation, JIT-C…

MV classique

MyAppli

main() {…

execution engineobject - loader…

AOP & MVV - 7

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 - 8

Alors quelle approche ?

Ne pas travailler pour le cas général (en général çafonctionne bien), mais travailler sur le minimum (KISS)

Extraire la complexité de la solution (système) vers unereprésentation de haut niveau

Notre solution : Virtualiser la machine virtuelle = MVVcoupe transversale depuis l ’application jusqu ’au matérielou… comment construire l’environnement d’exécution “idéale” (adaptée) àun problème particulier

AOP & MVV - 9

Solution : les MVVs

Virtualiser la machine virtuelle = MVVMVV = [MV]V est une plate-forme d'exécution (MV) dans laquelle onconstruit 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 toutesles MVlets

Environnement d’exécution « actif »

AOP & MVV - 10

Architecture de la MVV

Execution engine - Virtual processor

Object memory VVM

µ-VM

{CPU, memory, I/O}{OS,ø}

VMlet

loader "SuperVM""SuperVM"

My appli (type SuperVM)

(something to do)

My SuperVMlet

(define-instruction ())(define-object ())(define-syntax ())(define-primitives ())(define-loader ())(use-os-module ())

"SuperVM"

Application

loader

AOP & MVV - 11

Pourquoi l’approche MVV résout leproblème

Adaptabilité/spécialisation du support d'exécution auxdivers domaines - ou aux applications elles-mêmes (OS +langage)

Flexibilité/extensibilité pour ajouter/modifier desfonctionnalités, en fonction de l'application, de son utilisationou des évolutions matérielles (configuration/re-configuration +déploiement)

Interopérabilité pour l'échange de données entreapplications, pour la mobilité (code et/ou donnée) et pourfavoriser 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 - 12

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 programmationspé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 - 13

AOP (en bref)

Séparation des préoccupations, modularisation, inversionde 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 - 14

VMlets et aspects

Compilation (non ?) Système (oui !) : temps-réel, etc. Applications ?

AOP & MVV - 15{CPU, memory, I/O}

VVM

µ-VM

Système : VMlet-Bossa

{OS,ø}

VMlet-Bossa

(use-os-module ‘bossa’)

Politique LinuxPolitique EDF…

VM temps-réel

Loader : XWin

Bossa

Application (pid 13024)

Linux 2.4 (bossa)

scheduler

(root)

AOP & MVV - 16

Applications ?Exemple d’un cache Web

Cache local de documents distantsTrois politiques: remplacement, coopération, cohérencePour 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 minutesSe charge et se compile dans la MVV en 50 msSe change (si elle était déjà compilée) en 0,57 msBenchmarks : ajout/changement de politique, observation à la volée, modetrace…

L'API du cache Web EST le cache lui-même Est-ce un aspect ?

AOP & MVV - 17

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 - 18

Tissage ?VMlet de reconfiguration

;; VMlet reconfiguration command(xEvalSwitch filterPolicy (/ (httpR.sizerepository) 5))

;; 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))))))

AOP & MVV - 19

Cache Web auto-adaptable

VMlet cache Web flexible [CNN] + PANDORA (plate-formede monitoring auto-adaptable) (+ qq. lignes de codes Cd’intégrations PANDORA/VVM)

= Cache web flexible auto-adaptable [C/SPAN]

AOP & MVV - 20

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 écritpar ~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 - 21

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 pourchaque 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 MachineVirtuelle Universelle d'IBM) : basé sur une MV existante (Smalltalk), pas extensible

AOP & MVV - 22

Conclusion :vers un environnement d'exécution actif

Mise à jour de la plate-forme à la voléeDélocalisation des fonctionnalitésInteropé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'environnementd'exécution, n'est fait qu'une fois pour un domaine

optimisation agressive, spécialisation dynamique

Facilité de programmation (langage de haut niveau etservices 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 - 23

Questions ?

AOP & MVV - 24

Références - VVMhttp://vvm.lip6.fr/

VVM :[Bertil Folliot, Ian Piumarta, Fabio Riccardi. Virtual Virtual Machine. Cabernet Radical Workshop, Crète, Septembre1997.][Ian Piumarta, Bertil Folliot, Lionel Seinturier, Carine Baillarguet. Highly configurable operating systems: the VVMapproach. 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 DistributedComputing. 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 DistributedComputing. In Proc. 3rd International Workshop on Distributed Auto-adaptive and Reconfigurable Systems,ICDCS’2003, IEEE, Providence, Rhode Island, Mai 2003.]

AOP & MVV - 25

Références : VMlets

Réseaux actifs :[Christian Khoury, Bertil Folliot, Ian Piumarta. AAN: A Highly Reflective Active Network. In Proc. 20stIASTED Applied Informatics Conference, Innsbruck, Autriche, Février 2002.]

Web caching :[Ian Piumarta, Frederic Ogel, Carine Baillarguet, Bertil Folliot. Applying the VVM kernel to Flexible WebCaches. 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 languageapproach 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 spacesoftware 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.]