Programmation par aspect et Machine Virtuelle Virtuelle Plan

Programmation par aspect
et
Machine Virtuelle Virtuelle
Bertil Folliot
LIP6 / CNRS, Université Pierre et Marie Curie, Paris 6
INRIA Regal
[email protected]
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 - 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)
Application
loader
My SuperVMlet
(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
scheduler
VM temps-réel
VVM
µ-VM
Linux {OS,ø}
2.4 (bossa)
Bossa
{CPU, memory, I/O}
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. 20st
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