Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
AOP & MVV - 1
Programmation par aspectet
Machine Virtuelle Virtuelle
Bertil Folliot
LIP6 / CNRS, Université Pierre et Marie Curie, Paris 6INRIA Regal
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.
[email protected] 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.]