Transcription

1 CFSE'1 Rennes, 8 juin - 11 juin re Conf rence Fran aise sur les Syst mes d'exploitation Capture et restauration du contexte d'ex cution d'un thread dans l'environnement Java S. Bouchenak, D. Hagimont, X. Rousset de Pina Projet SIRAC (IMAG-INRIA) INRIA, 655 av. de l'europe, Montbonnot Saint Martin, France. Internet : Sara.Bouchenak@inria.fr R sum La machine virtuelle Java est actuellement port e sur la plupart des syst mes courants et fournit des services facilitant led veloppement d'applications distribu es tel RMI. Dans cette machine virtuelle, la mobilit est un aspect tr s important. En eet, Java fournit un m canisme de s rialisation d'objets permettant de capturer et de restaurer l' tat des objets Java et ainsi, de d placer ces objets entre di rentes machines. Java permet aussi le chargement dynamique des classes et leur d placement vers d'autres n uds. En revanche, Java ne fournit pas de m canisme permettant la capture et la restauration de l' tat d'un ot d'ex cution, la pile d'un ot Java n' tant pas accessible. Un tel m canisme serait int ressant et pourrait servir pour la migration d'agents mobiles ou comme service de base de capture de points de reprise pour la tol rance aux fautes. Dans cet article, nous pr sentons notre exp rience d'extension de la machine virtuelle Java qui vise fournir un m canisme de capture et de restauration de l' tat d'un ot d'ex cution Java. Nous d crivons la mise en uvre de ce m canisme et les r sultats des mesures pr liminaires de ses co ts. Abstract Today, distributed computing over the Internet is closely linked with Java. The Java virtual machine is ported to most of the current operating systems and provides many services which help developing distributed applications (e.g. RMI). In Java, mobility is a very important aspect. Java provides a serialisation mechanism which allows the capture and restoration of objects states and therefore to migrate objects between machines. It also allows classes to be dynamically loaded and therefore to be moved between nodes. However, Java does not provide a mechanism for capturing and restoring a thread state. The stack of a Java thread is not accessible. Such a mechanism would notably allow a thread to be checkpointed or migrated between dierent nodes. In this paper, we report on our experience which consisted in extending the Java virtual machine in order to allow the capture and restoration of a thread state. We overview the implementation of this extension and provide preliminary results of its evaluation.

2 1 Introduction Le d veloppement d'applications r parties, mettant en uvre un grand nombre de machines interconnect es par des r seaux g n raux et notamment l'internet, est un domaine de recherche en plein essor. Dans ce contexte, le langage objets Java a connu un rapide succ s. Le compilateur Java fournit un code interm diaire interpr t par une machine virtuelle, la Java Virtual Machine ou JVM. La JVM est implant e sur la plupart des stations de travail et des ordinateurs personnels, ce qui fait que le couple langage Java-JVM est consid r comme la plate-forme de r f rence des applications d velopp es pour l'internet. Un des int r ts majeurs de la tr s grande diusion de cette plate-forme est qu'elle permet de consid rer l'ensemble des machines virtuelles Java de l'internet comme une base homog ne pour construire des services r partis et notamment des services syst mes. Les m canismes auxquels nous nous int ressons dans cet article, appel s m canismes de capture-restauration de l' tat d'un ot de contr le (ou thread), sont ceux qui permettent le d placement d'un ot d'ex cution d'une JVM vers une autre, an d'y poursuivre son ex cution. Ces m canismes, seuls ou compl t s par d'autres, ont des applications dans plusieurs domaines comme : l' quilibrage de charge entre les machines [13], la diminution du trac r seau par d placement des clients vers leur serveur [5], l'administration de machines [15], la prise de point de reprise [16], ou enn la d nition de ots de contr le (ou agents) mobiles [4]. La fourniture de ces services sur les plates-formes Java d pend, en partie, de la disponibilit d'un m canisme de capture/restauration de l' tat d'un ot de contr le dans l'environnement Java. L'environnement Java fournit d j un service de s rialisation d'objets [19], qui permet de capturer l' tat d'un objet Java et de le restaurer. Il fournit en outre un service de chargement dynamique des classes qui permet de d placer le code entre des machines [18]. Ces deux services sont la base du d veloppement de syst mes dits agents mobiles, tels que les Aglets [9] ou Odyssey [7], permettant desotsdecontr le d' tre d plac s entre des machines. Cependant, comme Java ne fournit pas de service permettant d'acc der l' tat d'un ot de contr le au cours de son ex cution, il est dicile de red marrer l'application au point o elle a t interrompue. Donc ces syst mes ne fournissent qu'une mobilit dite faible [1]. Dans cet article, nous pr sentons une exp rience qui a consist tendre la machine virtuelle Java an qu'elle permette de capturer/restaurer l' tat d'un ot de contr le. Un prototype a t r alis par extension du kit de d veloppement Java (JDK 1.1.3). Le service r alis permet de capturer l' tat d'un ot de contr le, et d'utiliser l' tat captur pour initialiser un nouveau ot de contr le. Notre m canisme ne prend pas en compte les probl mes li s aux objets et aux communications que peut partager le ot de contr le avec d'autres. Cependant, le m canisme peut tre, ainsi que nous le montrons, facilement adapt aux besoins de l'application qui l'utilise. En eet, il lui permet de sp cier, pour certains types d'objets, des traitements suppl mentaires eectuer lors de la capture du contexte d'un ot d'ex cution et de sa restauration. An d' valuer le service fourni d'un point de vue fonctionnel, nous l'avons utilis pour r aliser un m canisme de migration d'agents mobiles et comme m canisme de base pour la capture de points de reprise d'une application. Ces deux exp riences d montrent la souplesse du m canisme que nous pr sentons. Pour valuer son ecacit, nous avons eectu un certain nombre de mesures an d'avoir, d'une part, une premi re valuation des co ts l mentaires qu'il induit et, d'autre part, des l ments de

3 comparaison de notre implantation avec celle, tr s di rente, r alis e par le projet WASP [6]. La suite de cet article est organis e comme suit. La section 2 pr sente nos motivations, un court tat de l'art et les aspects de la JVM utiles la compr hension de notre travail. Dans la section 3, nous d nissons les principes de conception de notre m canisme de capture/restauration du contexte d'ex cution d'un ot de contr le Java, suivis, dans la section 4, de la pr sentation de la r alisation de ce m canisme. La section 5 d crit les exp riences d'utilisation eectu es et donne une courte valuation quantitative de notre m canisme. Enn, dans la section 6 nous donnons quelques conclusions et perspectives de notre travail. 2 Contexte de travail Le m canisme de capture-restauration du contexte d'ex cution d'un ot de contr le a t int gr la version JDK de la Machine Virtuelle Java (JVM). Nous pr sentons, tout d'abord, les raisons de ce choix en les mettant dans la perspective des travaux qui ont t men s par d'autres quipes de recherche. Nous d crivons ensuite les quelques caract ristiques de la JVM qui sont n cessaires la compr hension de la suite de notre travail. 2.1 Motivations Le service de capture/restauration de l' tat d'un ot de contr le a de nombreuses applications, les principales tant la gestion de points de reprise et le d placement d'applications d'un n ud vers un autre (ou migration). Des tudes des principales techniques d velopp es dans le domaine sp cique de la migration de processus peuvent tre trouv es dans [14] et dans [12]. Cependant, si on limite le domaine de mise en uvre du m canisme l'environnement constitu par le langage Java et la JVM, le probl me peut tre abord selon deux approches. La premi re, que nous appelons gestion explicite, consiste laisser enti rement la charge du programmeur la gestion de la capture et de la reconstruction de l' tat du ot d'ex cution. Le programmeur doit donc ajouter du code qui eectue ce travail, en des points xes de l'application dits points de sauvegarde. En un point desauvegarde, le code ajout doit enregistrer l' tat de l'ex cution : il note la derni re instruction ex cut e ainsi que l' tat courant de l'application. La reprise de l'ex cution se fait partir du dernier point de sauvegarde enregistr. Cette solution manque de souplesse car la gestion des points de sauvegarde est enti rement lacharge du programmeur. Cette gestion explicite est cependant utilis e dans la plupart des applications utilisant des syst mes agents mobiles [4] tels que les Aglets [9] ou Mole [1]. La seconde approche est dite implicite, car elle consiste fournir un m canisme g n rique qui permet de capturer l' tat d'ex cution courant d'une application. Il sut que l'application appelle la primitive qui capture l' tat courant de l'ex cution, et l' tat de chacun des appels de m thodes en cours d'ex cution sera captur. Cette solution donne lieu deux implantations di rentes que nous d taillons ci-dessous. La premi re implantation consiste fournir un pr -processeur qui eectue un traitement suppl mentaire sur le code Java de l'application pour y inclure des instructions suppl mentaires ces instructions copient l' tat de l'ex cution (essentiellement lesvariables empil es)

4 dans une structure de donn es interm diaire. La motivation principale de cette m thode est de ne pas modier la machine virtuelle Java. Ainsi, lorsque l'on d sire capturer l' tat de l'application, il sut de prendre la structure interm diaire dont lecontenu jour par le code inject dans l'application. Lorsque l'on veut restaurer le contexte d'ex cution partir de cette structure, il sut d'ex cuter un programme qui interpr te nouveau les donn es de la structure pour initialiser l' tat d'un ot de contr le. Lorsqu'il sera activ, ce ot d marrera au point o l'ex cution a t interrompue lors de la capture. L'inconv nient de cette solution est double : elle a un impact non n gligeable sur les performances de l'application (d au code inject ) et l'initialisation du ot de contr le n cessite une r -ex cution partielle de l'application. Cette solution a notamment t mise en uvre par le projet WASP [6]. La seconde implantation consiste tendre la machine virtuelle Java an de rendre l' tat d'un ot de contr le accessible aux programmes Java. L'extension fournie doit permettre d'extraire l' tat pour le stocker dans une structure de donn es qui pourra tre ventuellement soit stock e dans un chier, soit transf r e sur un autre n ud via le r seau. Cette m thode doit galement permettre de reconstruire un ot d'ex cution dont l' tat initial est d ni au moyen de la structure de donn es contenant l' tat stock. Cette approche t utilis e dans la r alisation de la plate-forme agents mobiles Sumatra [17] et c'est celle que nous avons choisie pour deux raisons : Elle r duit l'impact du m canisme sur les performances de l'application. En eet, une mise en uvre qui consiste tendre la machine virtuelle Java est principalement native (en C), donc beaucoup moins co teuse que celle qui consiste utiliser un pr processeur pour injecter du code Java l'application. Cette r duction du surco t est obtenue en minimisant, d'une part, le travail induit par le m canisme sur l'activit normalede l'application et, d'autre part, le travail eectuer par le m canisme lors qu'il est utilis. Elle est coh rente avec le fait que les services fournis par ce m canisme sont g n riques ils ne sont pas uniquement utilisables par les applications voulant b n cier de la mobilit mais aussi comme base de m canismes pour la tol rance aux fautes. Contrairement la plate-forme Sumatra, qui fournit un service de mobilit pour ses agents, notre m canisme est plus g n rique et peut tre utilis aussi bien pour la mobilit que comme base de capture de points de reprise. Pour mettre en uvre ce service de capture/restauration de l' tat d'un ot de contr le, nous avons voulu fournir une interface qui soit la plus proche possible de celle qui est fournie par Java pour capturer ou restaurer l' tat d'un objet (s rialisation/d -s rialisation) [19]. En eet, notre objectif a t de permettre de s rialiser/d -s rialiser un ot de contr le. La s rialisation d'un ot de contr le revient capturer l' tat courant de ce ot, sous la forme d'une structure de donn es Java la d -s rialisation revient restaurer le ot de contr le partirde la structure de donn es construite pr c demment. 2.2 Contexte d'ex cution d'un ot de contr le Java Une Machine Virtuelle Java peut supporter l'ex cution de plusieurs ots de contr le ou threads [11]. Cette machine virtuelle manipule trois structures de donn es principales :

5 Classe Java Objet Java Zone de methodes Pile Java Tas d objets Figure 1: Contexte d' xecution d'un thread Java La pile Java. Une pile Java est associ e chaque ot de contr le Java delamachine virtuelle cette pile d crit l' tat d'avancement de l'ex cution du ot. La pile Java contient des r gions ou frames une r gion est cr e lors de l'appel d'une m thode Java puis d truite lors de la terminaison de la m thode associ e. La r gion contient, entre autres, les variables locales la m thode et les r sultats des calculs interm diaires. De plus, une r gion contient des registres tels que le registre de sommet de pile ou le registre compteur ordinal indiquant la prochaine instruction de code interm diaire (byte code) ex cuter (si la m thode associ e lar gion est une m thode Java et non une m thode dite nativedont le code n'est pas interpr t ). Le tas d'objets. Il y a un tas d'objets par machine virtuelle, partag par tous les ots de contr le de la machine virtuelle. Il regroupe l'ensemble des objets Java cr s et utilis s par les ots de contr le de la JVM. La zone des m thodes. La Machine Virtuelle Java poss de une zone des m thodes partag e par l'ensemble des ots de contr le de cette machine. Cette zone regroupe l'ensemble des classes Java utilis es par les ots de la JVM. Le contexte d'ex cution d'un ot de contr le Java, illustr par la Figure 1, est donc constitu des trois ensembles d'informations suivants : sa pile, son tas d'objets constitu s de l'ensemble des objets du tas de la JVM qu'il manipule (dont les r f rences sont dans sa pile), et sa zone de m thodes qui est constitu e des classes de la zone de m thodes de la JVM qu'il utilise. Les r f rences des classes utilis es par le ot de contr le sont galement stock es dans sa pile. 3 Conception d'un m canisme de capture/restauration du contexte d'ex cution d'un ot de contr le Java Nous d crivons, dans cette section, le principe du m canisme qui permet de capturer puis de reconstruire le contexte d'ex cution d'un ot de contr le Java. Nous d crivons ensuite les di rents probl mes que nous avons rencontr s et les choix de conception qui nous ont permis d'y faire face. Dans la suite, l'environnement JDK 1.1.3est d sign par le terme Java. De plus, chaque fois que cela ne pr te pas confusion, le terme ot sera utilis la place de ot de contr le Java.

6 3.1 Principe du m canisme Le m canisme que nous proposons doit fournir deux fonctions : la capture du contexte d'ex cution courant d'un ot de contr le Java puis la restauration de ce contexte. Ce m canisme permet donc, d'une part, d'interrompre un ot Java en cours d'ex cution et d'extraire son contexte courant et, d'autre part, d'int grer ce contexte d'ex cution un nouveau ot Java qui, une fois lanc, d marre son ex cution au point m me o le pr c dent a t interrompu. L'extraction du contexte d'ex cution d'un ot Java revient construire une structure de donn es qui contient toutes les informations permettant de restaurer ce contexte. Cette structure de donn es doit donc contenir toutes les informations n cessaires la reconstruction de la pile du ot, de son tas d'objets et de sa zone de m thodes. Pour extraire le contexte d'ex cution d'un ot Java, il faut tout d'abord capturer la pile qui est associ e ce ot. Il faut ensuite identier l'ensemble des objets et des classes Java qui sont utilis s par ce ot ceci se fait en parcourant la pile Java du ot pour y r cup rer les r f rences vers les objets et les classes Java. Finalement, une structure de donn es Java est construite, contenant toutes ces informations. L'int gration d'un contexte d'ex cution un ot Java revient reconstruire un contexte d'ex cution partir de la structure de donn es obtenue lors d'une op ration d'extraction. Cette op ration d'int gration consiste donc construire un nouveau ot de contr le Java, ayant une pile, un tas d'objets et une zone de m thodes identiques ceux du ot ayant subi l'op ration d'extraction. 3.2 Principaux probl mes Un des probl mes rencontr s lors de la capture du contexte d'ex cution d'un ot Java est le probl me du type des valeurs rang es dans la pile Java d'un ot. En eet, la pile Java d'un ot contient les valeurs des calculs interm diaires et les valeurs des variables locales des m thodes en cours d'ex cution. Ces valeurs peuvent tre de di rents types : entier, r el, r f rence Java etc. Mais la structure de pile Java ne donne aucune information sur le type des valeurs qui y sont contenues. Cela entra ne deux dicult s. La premi re concerne l'identication du tas d'objets Java associ ce ot. En eet, pour identier l'ensemble des objets Java utilis s par un ot, il faut parcourir la pile Java dece ot et r cup rer l'ensemble des r f rences Java qui y sont utilis es. Mais comment sait-on qu'une valeur sur la pile est une r f rence Java plut t qu'un entier? La seconde dicult engendr e par ce probl me de types est li e au fait que la pile Java est une structure qui d pend de l'architecture de la machine physique (structure C). Le codage des donn es contenues dans cette pile di re donc d'une architecture de machine une autre. Donc, pour que notre m canisme de capture/restauration puisse fonctionner entre machines h t rog nes, il faut que la structure de donn es construite lors de la capture contienne les informations relatives aux types des valeurs contenues dans la pile. On est donc face au m me probl me que pr c demment. Un autre probl me rencontr concerne les adresses absolues contenues dans les registres de la pile Java. En eet, la pile Java d'un ot contient des pseudos registres comme le compteur ordinal (pc) qui pointe vers la prochaine instruction ex cuter ou le registre de sommet de pile. Les valeurs contenues dans ces registres sont des adresses virtuelles absolues qui n'ont plus de sens lors de la restauration de la pile et qui, donc, doivent tre

7 recalcul es. En dehors de ces deux probl mes, se posent les probl mes relatifs la gestion des donn es et des communications partag es par les ots de contr le. En eet, que se passe-t-il lorsqu'un ot se d place d'un site source vers un site destination alors qu'il acc dait des objets utilis s galement par d'autres ots du site source? Comment sont g r es les communications entre ots de contr le lorsqu'un des ots mis en uvre se d place d'un site un autre? 3.3 Choix de conception Nous pr sentons les solutions que nous avons choisi d'apporter aux probl mes pr sent s ci-dessus. En ce qui concerne le probl me du type des valeurs contenues dans la pile Java d'un ot, il est n cessaire, lors de la capture du contexte du ot, de r cup rer le type de chacune des valeurs se trouvant dans la pile Java. Le seul moment o le type d'une valeur rang e dans la pile peut tre connu est losqu'elle est empil e. En eet, les instructions de code interm diaire sont typ es : elles ne s'appliquent qu' des valeurs d'un m me type [11]. Par exemple, les instructions : lstore_<n> : stocke l'entier (long), situ en sommet de pile, dans la n-i me variable locale de la r gion associ e la m thode courante. aload_<n> : charge, au sommet de la pile, la r f rence Java stock e dans la n-i me variable locale de la r gion associ e la m thode courante. Pour obtenir le type des valeurs contenues dans la pile Java d'un ot, nous avons tendu l'interpr te Java an de g rer une pile de types, parall le la pile Java. Cette pile de types donne, pour chaque valeur dans la pile Java, le type de cette valeur. La construction de cette pile de types se fait au fur et mesure de l'interpr tation du code ex cut par le ot ainsi, l'instruction interpr t e de code interm diaire nous donne l'information sur le type de la valeur empil e. De cette fa on, lors de la capture du contexte d'ex cution d'un ot, nous poss dons le type des valeurs rang es dans la pile Java du ot. Nous pouvons donc identier l'ensemble des objets Java utilis s par ce ot ainsi que le type des autres valeurs rang es dans la pile Java. Lors de la restauration du contexte, le tas d'objets du ot pourra tre reconstitu et il n'y aura pas de probl me d l'h t rog n it des machines. Quant au probl me pos par les adresses absolues contenues dans la pile Java d'un ot, nous l'avons classiquement r solu en transformant les adresses absolues en d placements. Pour ce qui est des adresses absolues vers la pile, nous calculons des d placements relatifs au d but de pile, et pour les adresses vers le code, relativement au d but du code. Pour ce qui est du probl me des objets partag s et des communications ouvertes entre di rents ots, nous avons d lib r ment choisi de ne pas fournir de solution ces probl mes au niveau de la JVM. Notre objectif, dans un premier temps, est de fournir un nouveau m canisme pour le JDK, un m canisme de capture/restauration de base du contexte d'ex cution d'un ot Java nous ne nous pla ons donc pas dans le cadre d'un syst me r parti.. Mais, comme nous le montrons en 5.1.4, certains de ces probl mes, comme la communication entre ots, peuvent tre r solus en adaptant notre m canisme aux besoins de l'application qui l'utilise. Par contre, le probl me des objets partag s par di rents ots n'est pas r solu au niveau de notre m canisme cette gestion reviendrait donc au

8 programmeur de l'application qui d ciderait soit de n'appliquer ce m canisme que sur un ot isol soit de fournir un syst me de d signation globale des objets de son application. 4 R alisation du m canisme de capture/restauration du contexte d'ex cution d'un ot de contr le Java Dans cette section, nous d crivons le contexte de r alisation de notre m canisme, puis l'extension apport e la JVM gr ce l'ajout de la classe MobileThread et nous donnons enn quelques r sultats techniques apport s par cette r alisation. 4.1 Plate-forme de r alisation : JVM Le m canisme de capture/restauration du contexte d'ex cution d'un ot de contr le que nous avons r alis a t int gr la Machine Virtuelle Java et, plus pr cis ment, au JDK [18]. Le code source du JDK 1.1.3, sur lequel nous nous sommes appuy s, est destin plusieurs plates-formes telles que : Solaris sur des architectures Sparc ou de type x86, ou Microsoft Windows NT et Microsoft Windows 95. Ce JDK est constitu d'une arborescence importante, comprenant autour de lignes de code Java, lignes de code C/C++ et lignes de code assembleur. 4.2 Notre extension : classe MobileThread Le m canisme que nous avons r alis [2] permet, d'une part, d'interrompre un ot de contr le Java en cours d'ex cution, d'extraire son contexte courant et de construire une structure de donn es qui synth tise ce contexte et, d'autre part, d'int grer un contexte d'ex cution un nouveau ot et de lancer son ex cution pour qu'il reprenne au point o le pr c dent a t interrompu. Pour cela, nous avons construit une classe MobileThread [3], qui fait partie du package java.lang. du JDK [18] et qui est une sous-classe de la classe Thread de Java. La classe MobileThread caract rise les ots Java dont lecontexte d'ex cution peut tre captur puis restaur. Par ailleurs, nous avons construit une classe ExecutionEnvironment dont les objets sont des structures de donn es synth tisant le contexte d'ex cution d'un ot de la classe MobileThread. Pour des raisons de protection, les variables et les m thodes de cette classe sont priv es : ces variables ne peuvent pas tre manipul es et ces m thodes ne peuvent pas tre appel es par des programmes Java utilisateurs. Seul notre m canisme de capture/restauration du contexte d'ex cution d'un ot peut manipuler des objets ExecutionEnvironment ainsi, nous pouvons tre s rs qu'une structure synth tisant le contexte d'ex cution d'un ot est toujours bien construite. L'interface de la classe MobileThread est illustr e par la Figure 2. Un ot de la classe MobileThread poss de une variable ExecEnv qui est un objet ExecutionEnvironment. Cette variable n'est initialis e qu'au moment de l'extraction du contexte d'ex cution du ot o elle contiendra toutes les informations relatives ce contexte et n cessaires sa restauration. La m thode extractexecenv sert capturer le contexte d'ex cution courant d'un ot. Elle commence, tout d'abord, par interrompre le ot en cours d'ex cution et capturer son contexte courant cecontexte est aect la variable ExecEnv du ot. Une fois la capture

9 abstract class MobileThread extends Thread implements java.io.serializable { public public public ExecutionEnvironment ExecEnv; void extractexecenv(boolean tostop, String[] args); abstract void transferexecenv(executionenvironment execenv, String[] args); public static MobileThread integrateexecenv(executionenvironment execenv); Figure 2: Interface d'utilisation de la classe MobileThread du contexte eectu e, l'ex cution de ce ot peut tre soit d nitivement interrompue, si le param tre tostop est vrai, soit relanc e, si le param tre tostop est faux. Ainsi, cette primitive peut servir galement eectuer un clonage de ot distance. Un dernier traitement eectu par la m thode extractexecenv est l'appel de la m thode transferexecenv. Le param tre args de la m thode extractexecenv sera le param tre pass lors de l'appel de transferexecenv. La m thode transferexecenv d nit le traitement relatif au transfert du contexte d'ex cution d'un ot, apr s sa capture. Cette m thode est abstraite (son interface est d nie mais pas son corps) car sa mise en uvre d pend des besoins de l'application utilisant notre m canisme. En eet, une application utilisant la migration de ot doit transf rer le contexte du ot vers une machine distante tandis qu'une application ayant besoin d'une sauvegarde de l' tat du ot pour une reprise ult rieure doit stocker le contexte du ot sur disque. La mise en uvre de la m thode transferexecenv est donc la charge du programmeur de l'application utilisant notre m canisme. Le param tre execenv de cette m thode est le contexte d'ex cution qui va tre transf r ou copi. D'autre part, du fait que le traitement eectu par la m thode transferexecenv di re d'une application une autre, nous proposons un second param tre g n rique qui puisse contenir tous les param tres dont aurait besoin cette m thode. Ce param tre est le param tre args. La m thode integrateexecenv sert restaurer un contexte d'ex cution. Cette m thode cr e un nouveau ot et y int gre le contexte d'ex cution execenv pass en param tre. Une fois l'int gration eectu e, l'ex cution du nouveau ot est lanc e, celle-ci reprend au point o elle a t interrompue. 4.3 R sultats techniques Pour la r alisation de notre m canisme, nous avons, d'une part, tendu le package java.lang. du JDK pour l'ajout de nouvelles classes, telles que les classes-utilisateur MobileThread et ExecutionEnvironment et des classes internes n cessaires nos traitements. D'autre part, pour produire une pile de types parall le la pile Java d'un ot (voir 3.3), il fallait que l'interpr te Java soit tendu. Mais pour ne pas alourdir les performances d'ex cution des programmes Java n'utilisant pas notre m canisme, nous avons propos un autre interpr te Java cet interpr te propos eectue les m mes traitements par rapport l'interpr tation du byte code, mais g re en plus la pile de types associ e au ot. Cet interpr te n'est utilis que par les ots de contr le de la classe MobileThread ainsi, les

10 performances des autres programmes Java n'en p tissent pas. La r alisation de notre m canisme est modulaire et peut donc tre facilement port e vers une autre Machine Virtuelle Java. Cette r alisation a n cessit 700 lignes de code Java et quelques lignes de code C. 5 Exp rimentation et valuation Dans cette section, nous d crivons, tout d'abord, les premi res exp riences eectu es avec notre m canisme de capture/restauration du contexte d'ex cution d'un ot Java. Nous pr sentons ensuite l' valuation des di rents co ts induits par notre m canisme. 5.1 Exp rimentations Les premi res exp rimentations eectu es avec notre m canisme de capture/restauration du contexte d'ex cution d'un ot Java servent illustrer le mode d'utilisation de ce m canisme par le programmeur d'applications n cessitant la migration, le clonage distance de ots Java ou la sauvegarde de l' tat d'un ot puis sa reprise. Nous illustrons galement l'adaptabilit de notre m canisme. Dans ce qui suit, nous d taillons l'exp rimentation de la migration et d crivons, pour les autres exp rimentations, la di rence entre leur mise en uvre et celle qui concerne la migration. Le code de ces exp rimentations peut tre trouv dans [3] Migration de ot de contr le Java Par migration, nous entendons le d placement de l'ex cution d'un ot d'une machine source vers une machine destination. Ce d placement doit se faire de telle sorte que l'ex cution du ot sur la machine destination reprenne au point o elle a t interrompue sur la machine source. La migration d'un ot Java doit donc interrompre l'ex cution du ot sur la machine source et extraire son contexte courant. Ce contexte est ensuite transf r vers la machine destination o il est int gr un nouveau ot Java. Finalement, l'ex cution de ce nouveau ot est lanc e sur la machine destination et le ot initial sur la machine source est d truit. Pour exp rimenter la migration d'un ot Java, nous avons tout d'abord crit une classe Java que nous appelons MigratingThread. Cette classe est une sous-classe de la classe MobileThread et elle fournit une implantation de la m thode abstraite transferexecenv. La m thode transferexecenv poss de un premier param tre repr sentant uncontexte d'ex cution de ot et un second param tre qui est un tableau contenant l'adresse IP et le num ro de port de la machine destination. Dans le cas de la migration, le r le de cette m thode est de transf rer le contexte d'ex cution, pass en param tre, vers la machine destination dont l'identication est galement pass e en param tre. Ce transfert est r alis gr ce l'op ration de s rialisation de Java. Nous avons ensuite lanc deux Machines Virtuelles Java : une machine source et une machine destination. Sur la machine source, nous avons cr un ot, de la classe MigratingThread, qui ex cute un programme Java quelconque. Au cours de son ex cution, ce ot appelle la m thode extractexecenv avec le param tre tostop vrai et le param tre args qui est un tableau contenant l'adresse IP et le num ro de port de la machine destination. Cet appel provoque la capture du contexte d'ex cution courant du ot, le transfert de ce contexte verslamachine destination et l'arr t d nitif de ce ot. La machine destination

11 re oit ensuite un contexte d'ex cution, gr ce l'op ration de d -s rialisation de Java, puis la m thode integrateexecenv est appel e. Cet appel provoque la cr ation d'un nouveau ot de la classe MigratingThread, ce nouveau ot poursuit l'ex cution du premier au point o elle a t interrompue Clonage de ot de contr le Java distance Le clonage d'un ot est la cr ation d'un nouveau ot (appel clone) qui a le m me tat d'ex cution que le premier ces deux ots poursuivent ensuite leur ex cution s par ment. Le clonage d'un ot distance est la cr ation d'un ot clone mais sur une machine distante. Un des int r ts du clonage distance est qu'il peut servir dupliquer l'ex cution d'une application sur plusieurs machines pour permettre cetteapplication de tol rer les fautes [10]. Si, pour un ot qui s'ex cute sur une machine source, nous voulons cr er un clone sur une machine destination, ceci revient eectuer une migration du ot de la machine source verslamachine destination avec la seule di rence que l'ex cution du ot, sur la machine source, est poursuivie au lieu d' tre d nitivement arr t e. La mise en uvre du clonage de ot distance en utilisant notre m canisme est donc exactement la m me que celle de la migration de ot, avec la seule di rence que la m thode extractexecenv est appel e avec le param tre tostop faux Sauvegarde/Reprise d'un ot de contr le Java L'exp rimentation pr sent e ici illustre la sauvegarde de l' tat d'un ot Java dans un chier puis sa restauration partir du contenu du chier. L'op ration de sauvegarde de l' tat du ot Java doit donc interrompre l'ex cution de ce ot, extraire son contexte courant et le sauver dans un chier. Le ot peut ensuite poursuivre son ex cution. En cas de panne, la restauration de l' tat sauvegard r cup re le dernier contexte stock dans le chier et l'int gre un nouveau ot Java dont l'ex cution sera lanc e cette ex cution reprendra au point o elle a t interrompue lors de la derni re sauvegarde dans le chier. L'exp rimentation de la sauvegarde/reprise d'un ot Java et similaire celle de la migration. La seule di rence entre ces deux mises en uvre r side dans le fait que, pour la sauvegarde/reprise, le contexte captur du ot est stock dans un chier au lieu d' tre transf r vers une autre machine travers le r seau. Pour cela, nous avons crit une m thode extractexecenv dont le r le est de sauvegarder un contexte d'ex cution dans le chier dont le nom est pass en param tre de la m thode. Le transfert du contexte d'ex cution vers le chier est r alis gr ce l'op ration de s rialisation de Java Adaptation de la migration d'un ot de contr le Java Cette derni re exp rimentation sert illustrer la possibilit d'adapter notre m canisme de capture/restauration du contexte d'ex cution d'un ot aux besoins de l'application qui l'utilise. En eet, notre m canisme permet de capturer le contexte d'ex cution global d'un ot Java ce contexte est ensuite enti rement transf r (vers une machine distante ou vers un chier). Par d faut, tous les objets Java utilis s par le ot sont transf r s. Mais le transfert de certains objets utilis s par le ot peut tre d nu de sens. Ainsi, le transfert d'un objet repr sentant un canal de communication ou de tout objet fortement d pendant de la machine sur laquelle s'ex cute le ot peut conduire des incoh rences. Une solution ce probl me est d'adapter notre m canisme aux besoins de l'application qui l'utilise, en lui permettant de sp cier, pour certains types d'objets Java, des traite-

12 ments suppl mentaires eectuer lors de la capture et de la restauration du contexte d'ex cution d'un ot. Pour illustrer ce principe, nous avons implant une application de type Client-Serveur, compos e de plusieurs sites clients et d'un site serveur connu par tous. Nous avons lanc une Machine Virtuelle Java sur chacun de ces sites. Un site client peut supporter l'ex cution de plusieurs ots Java, ces ots tant des objets de la classe MigratingThread que nous avons crite (voir 5.1.1). Un ot, sur le site client, communique avec le serveur via un canal de communication, un canal tant repr sent par un objet Java d'une classe nomm e MyConnector. Que se passe-t-il lorsqu'un ot, sur un site client source, se d place vers un site client destination? Et, plus pr cis ment, comment est trait, lors de la migration, l'objet MyConnector qui reliait le ot sur le site client source au serveur? L'adaptation que nous avons mise en uvre se fait en deux tapes. La premi re tape se d roule au moment du transfert du contexte d'ex cution du ot o, pour chaque objet MyConnector utilis par le ot, un message de d connexion est envoy au serveur et le canal ferm. La seconde tape se fait au moment de la restauration du contexte (sur le site destination) o, pour chaque objet MyConnector utilis par l'ancien ot, un nouvel objet MyConnector est cr puis connect au serveur ainsi, la communication entre le serveur et le ot transf r vers le site client destination est r tablie. Ces deux tapes ont t r alis es, respectivement, lors des op rations de s rialisation et de d -s rialisation de Java. En eet, nous avons surcharg les m thodes Java writeobject (s rialisation) et read- Object (d -s rialisation) de la classe MyConnector pour qu'elles eectuent les traitements correspondant aux deux tapes pr sent es pr c demment. 5.2 valuation Nous pr sentons ici le r sultat des mesures pr liminaires que nous avons eectu es sur notre prototype. Ces premi res mesures visent valuer, d'une part, le co t de notre m canisme et, d'autre part, le surco t induit par notre m canisme sur les applications qui ne l'utilisent pas Co t de notre m canisme Nous consid rons la migration d'un ot de contr le entre deux machines virtuelles Java et nous nous proposons de mesurer le co t de la migration proprement dite. Le travail eectu lors de la migration d pend du nombre, de la taille, et de la nature du contenu des r gions stock es dans la pile Java duot.nous ne nous int ressons dans la suite qu' l'inuence du nombre de r gions (frames. Nous voulons donc quantier la variation du co t de la migration du ot en fonction du nombre de r gions stock es dans la pile Java deceot. Nous souhaitons aussi comparer les r sultats obtenus soit en utilisant notre m canisme de capture/restauration du contexte d'ex cution d'un ot, soit en utilisant le m canisme fourni par WASP [6]. Pour atteindre ce but, nous avons crit un programme Java qui calcule r cursivement la factorielle d'un entier n et migre quand les n contextes intervenant dans le calcul sont empil s. Nous avons produit deux versions de ce programme, l'une qui utilise notre m canisme et l'autre qui utilise le m canisme fourni par WASP. Pour ce qui est du transfert du contexte d'ex cution du ot, nous avons utilis le m canisme de s rialisation/d -s rialisation standard de Java, pour les deux versions du programme. Cette exp rimentation a t r alis e entre deux machines virtuelles Java (JDK 1.1.3), install es sur des processeurs Sparc

13 Temps d une migration (en ms) Notre mecanisme Mecanisme de WASP Nombre de regions Figure 3: Co t de la migration d'une fr quence de 167 Mhz et sur le syst me Solaris 2.5 le r seau reliant ces machines tant de 10Mb/s. Les gures 3 et 4 donnent respectivement le temps de migration d'un ot et le temps de transfert du contexte d'ex cution d'un ot en fonction du nombre de r gions sur la pile Java deceot. La gure 3 donne, en trait plein, le temps de migration en utilisant notre m canisme et, en pointill s, le temps de migration en utilisant le m canisme de WASP. Alors que les deux courbes sont tr s voisines au voisinage de l'origine (faible nombredezoneactives sur la pile), la technique d'implantation de la migration par injection (WASP) est de moins en moins ecace au fur et mesure que le nombre de zones actives empil es cro t. Pour tenter de localiser o se situe cette perte d'ecacit relative entre la m thode utilis e par WASP et la n tre, nous avons mesur, d'une part, la taille des contextes transport s lors de la migration et, d'autre part, le temps de transfert de ces contextes. Le r sultat de cette mesure montre que notre m canisme donne lieu des contextes dont la taille est toujours un peu plus grande que celle des contextes engendr s par WASP. En revanche, le transfert de nos contextes est moins co teux que celui des contextesdewasp. Le temps de transfert du contexte (temps de s rialisation augment du temps transfert r seau et du temps de d -s rialisation) est illustr par la gure 4. La di rence entre les co ts de transfert des contextes ne peut donc tre due qu' la di rence de complexit des structures de donn es synth tisant ces contextes des deux ex cutions. Par ailleurs, des mesures illustr es par les gures 3 et 4, on peut d duire les co ts induits par les traitements propres la capture et la restauration des contextes d'ex cution. Le co t d'une migration est gal la somme des co ts de capture, de transfert et de restauration du contexte. Les co ts moyens de capture/restauration reviendraient donc 7 ms pour notre m canisme et 25 ms pour le m canisme fourni par WASP. Cette di rence est due au fait que notre m canisme a t int gr la machine virtuelle Java (implantation principalement native, en C) alors que celui de WASP est mis en uvre au dessus de la machine virtuelle (injection de code Java dans l'application).

14 Temps d un transfert (en ms) Notre mecanisme Mecanisme de WASP Nombre de regions Figure 4: Co t du transfert du contexte d'ex cution Surco t induit par notre m canisme Nous voulons v rier ici que notre m canisme n'induit des co ts suppl mentaires que lorsqu'il est utilis ou susceptible d' tre utilis par une application. Pour le montrer, nous avons mesur le temps d'ex cution d'un m me programme ex cut selon di rents sc narios : le programme est ex cut par un ot de la classe Thread, sur une machine virtuelle Java standard (JDK 1.1.3). le programme est ex cut par un ot de la classe Thread, sur la machine virtuelle Java que nous avons tendue (JDK tendu). le programme est ex cut par un ot de notre classe MobileThread, sur la machine virtuelle Java que nous avons tendue (JDK tendu). An de compl ter notre comparaison avec WASP, nous avons d ni un dernier sc nario : le programme, trait par WASP est ex cut sur la machine virtuelle Java standard (JDK 1.1.3) Type de JVM Classe du ot Temps d'ex cution (en ms) JVM standard classe Thread 0,18 JVM tendue classe Thread 0,18 JVM tendue classe MobileThread 1,85 JVM standard classe WASP 25 Figure 5: Co t d'une ex cution de la fonction factorielle(100) La gure 5 pr sente les co ts d'ex cution de ces divers sc narios, pour un programme calculant la factorielle de 100. En comparant les r sultats des deux premiers sc narios, nous constatons qu'un ot de la classe Thread, s'ex cutant sur la JVM que nous avons tendue, ne subit aucun surco t le temps de calcul, dans ces deux cas, est de 0,18 ms. En revanche, dans le troisi me sc nario, le ot de la classe MobileThread a un temps d'ex cution

15 de 1,85 ms. Cette ex cution, qui peut utiliser notre m canisme, dure environ 10 fois plus longtemps que l'ex cution normale. Ce surco t r sulte des traitements suppl mentaires eectu s par notre machine relativement au contexte d'ex cution des ots de la classe MobileThread. On pourrait consid rer comme excessif le co t rajout par notre m canisme pour simplement suivre l' volution du contexte d'ex cution du ot. Cependant, ce co t est comparer avec les 25 ms, mesur es pour le dernier sc nario. Ce dernier surco t, d au code Java rajout, multiplie par environ 130 le temps d'ex cution de base de la factorielle. Il est clair que notre implantation pourrait tre beaucoup plus ecace si le m canisme avait t r ellement int gr la JVM par ses concepteurs. 6 Conclusion et perspectives Alors que la machine virtuelle Java fournit la plupart des m canismes de base permettant le d placement des objets, elle ne permet pas, dans sa version actuelle, le d placement d'un ot d'ex cution (thread). En eet, la pile d'un ot d'ex cution n'est pas accessibles au programme Java. L'objectif de notre travail tait de rem dier cette d cience en ajoutant un m canisme permettant de capturer et de restaurer l' tat d'un ot de contr le. Deux approches permettent de construire un tel m canisme. La premi re, utilis e par WASP [6], consiste op rer enti rement au niveau utilisateur en ajoutant, au moyen d'un pr -processeur, du code et des donn es l'application ex cut e. La seconde consiste tendre la machine virtuelle Java pour qu'un programme ait acc s la pile du ot de contr le qui l'ex cute. C'est cette derni re voie que nous avons choisie. D'une part, parce qu'elle permet de fournir directement le m canisme d'autres applications que la construction d'agents mobiles et, d'autre part, parce qu'elle permet une implantation plus ecace. Le prototype a t r alis par extension du JDK An d' valuer ce prototype d'un point de vue fonctionnel, nous l'avons utilis la fois pour le support de la migration forte dans une plate-forme agents mobiles et pour mettre en uvre une gestion de points de reprise. Les premi res mesures eectu es sur le prototype montrent que le JDK que nous avons tendu n'induit aucun co t suppl mentaire sur les applications qui n'utilisent pas notre m canisme. Elle montre galement que le co t de ce m canisme est raisonnable, surtout si on le compare au co t de celui fourni par WASP. Les performances du m canisme propos pourraient tre meilleures si celui-ci tait r ellement int gr la machine virtuelle par ses constructeurs. Ce travail se poursuit actuellement. Des mesures compl mentaires sont en cours, le but tant, tout d'abord, d'approfondir et d' largir d'autres implantations la comparaison des mises en uvre de ce m canisme. Les perspectives plus long terme concernent des aspects non encore trait s du probl me. Nous n'avons pas abord les probl mes li s la protection des piles que nous rendons accessibles aux programmes Java. Il est important de ne pas introduire de faille dans le syst me de protection de Java. Enn, ce m canisme devrait constituer, avec le m canisme d'objets r partis fourni par Javanaise [8], un premier pas vers une machine Java r partie. Bibliographie 1. J. Baumann, F.Hohl, M. Straber et K. Rothermel. Mole - Concepts of Mobile Agent

16 System. WWW Journal, Special issue on Applications and Techniques of Web Agents, S. Bouchenak-Khelladi. M canismes pour la Migration de Processus - Extension de la Machine Virtuelle Java. Rapport de Magist re, Universit Joseph Fourier, Grenoble, France, S. Bouchenak-Khelladi. Extended Java Platform Core API. URL : bouchena/recherche/dea/myapi/packages.html 4. D. Chess, C. Harrison et A. Kershenbaum. Mobile Agents: Are They a Good Idea? T.J. Watson Research Center, IBM Research Division, mars URL : 5. F. Douglis et B. Marsh. The Workstation as a Waysttion : Integrating Mobility into Computing Environment. The Third Workshop on Workstation Operating System (IEEE), avril S. F nfrocken. Transparent Migration of Java-based Mobile Agents(Capturing and Reestablishing the State of Java Programs). Proceedings of Second International Workshop Mobile Agents 98 (MA'98), Stuttgart, Allemagne, septembre General Magic. Odyssey Web Site. URL: 8. D. Hagimont et D. Louvegnies. Javanaise : Distributed Shared Objects for Internet Cooperative Applications. Middleware'98, Angleterre, septembre IBM Tokyo Research Labs. Aglets Workbench : Programming Mobile Agents in Java, URL : J. Kim, H. Lee et S. Lee. Replicated Process Allocation for Load Distributed in Fault- Tolerant Multicomputers. IEEE Transactions on Computers, pages , avril T. Lindholm et F. Yellin. Java Virtual Machine Specication. Addison Wesley, D. S. Milojicic, F. Douglis, Y. Paindaveine, R. Wheeler et S. Zhou. Process Migration Survey. The Open Group research Institute, Rapport Technique, volume 5, mars URL : D. A. Nichols. Using Idle Workstations in a Shared Computing Environment. Proceedings of the Eleventh ACM Symposium on Operating Systems Principles, novembre M. Nuttall. A Brief Survey of Systems Providing Process or Object Migration Facilities. Operating Systems Review, octobre I. Oueichek. Conception et r alisation d'un noyau d'administration pour un syst me r parti objets persistants. Th se de Doctorat, Institut National Polythechnique de Grenoble, France, octobre T. Osman et A. Bargiela. Process Checkpointing in an Open Distributed Environment. Proceedings of European Simulation Multiconference, ESM'97, juin M. Ranganathan, A. Acharya, S. D. Sharma et J. Saltz. Network-aware Mobile Programs. Proceedings of the USENIX Annual Technical Conference, Anaheim, Californie, Sun Microsystems. JDK 1.1 Documentation, Sun Microsystems. URL : Sun Microsystems. Object Serialization, Sun Microsystems. URL :