Mécanismes pour la migration de processus

Université Joseph Fourier Institut National Polytechnique de Grenoble U.F.R. Informatiques & Mathématiques Appliquées ENSIMAG I.M.A.G. DEA D INFORMATIQUE : SYSTEMES ET COMMUNICATIONS Projet présenté par : Sahra Bouchenak-Khelladi Mécanismes pour la migration de processus Extension de la machine virtuelle Java Effectué au laboratoire : INRIA Rhônes-Alpes Projet SIRAC Date : 12 juin 1998 Jury : Didier Bert Jacques Briat Andrzej Duda Sacha Krakowiak UFR Informatique et Mathématiques Appliquées Service scolarité Adresse locale : 60, avenue de la Chimie Domaine Universitaire Saint Martin d ères/gières Adresse postale : B.P. 53-38041 Grenoble cedex 9 Tel. : 04-76-63-57-90 Fax : 04-76-51-43-78

Remerciements Je tiens à remercier Monsieur Roland Balter de m avoir reçue au sein du projet Sirac. Je tiens à remercier également le Professeur Sacha Krakowiak pour son soutien tout le long de ce stage de DEA. Et je remercie particulièrement Messieurs Xavier Rousset de Pina et Daniel Hagimont pour leur soutien permanent et pour les discussions qui ont animé ce stage.

Mécanismes pour la migration de processus Extension de la machine virtuelle Java Sommaire Introduction...1 1 La migration de processus...5 1.1 Définitions élémentaires... 5 1.1.1 Processus et contexte d exécution... 5 1.1.2 Qu est-ce que la migration de processus... 6 1.2 Motivations... 6 1.3 Algorithme général de migration de processus... 7 1.4 Travaux antérieurs... 8 1.4.1 Classification des travaux sur la migration de processus... 8 1.4.1.1 Degrés de mobilité...8 1.4.1.2 Hétérogénéité...9 1.4.1.3 Portabilité...9 1.4.2 Alternatives à la migration de processus... 10 1.4.2.1 Processus clone...10 1.4.2.2 Agents mobiles et langages sûrs et interprétés...10 1.5 Problèmes rencontrés lors de la réalisation de la migration de processus... 10 1.5.1 Hétérogénéité... 10 1.5.2 Maintien de la validité des canaux ouverts... 11 1.5.3 Maintien des communications entre processus... 11 2 Conception de mécanismes de migration de processus dans Java...13 2.1 Objectifs de la réalisation... 13 2.2 Contexte de réalisation... 14 2.2.1 Le langage Java... 14 2.2.1.1 Un langage orienté-objet...14 2.2.1.2 Un langage interprété...14 2.2.1.3 La machine virtuelle Java...15 2.2.2 Positionnement par rapport aux travaux antérieurs... 16 2.2.3 Problèmes et solutions... 16 2.3 Principes des mécanismes de migration à réaliser... 17

3 Machine Virtuelle Java...19 3.1 Introduction... 19 3.1.1 Présentation générale... 19 3.1.2 Exemple introductif... 20 3.2 Structure de la machine virtuelle Java... 21 3.2.1 Zones de données d exécution... 21 3.2.1.1 Le registre pc...21 3.2.1.2 La pile Java...21 3.2.1.3 Le tas...21 3.2.1.4 La zone de méthodes...22 3.2.1.5 Le constant pool...22 3.2.1.6 Les piles de méthodes natives...22 3.2.2 Frames... 22 3.2.2.1 Les variables locales...22 3.2.2.2 Les piles d opérandes...23 3.2.2.3 La liaison dynamique...23 3.3 Fonctionnement de la machine virtuelle Java... 24 3.3.1 Démarrage de la machine virtuelle... 24 3.3.2 Chargement... 24 3.3.3 Liaison... 25 3.3.4 Initialisation... 25 3.3.5 Terminaison de la machine virtuelle... 25 3.4 Threads Java...25 3.4.1 Structure du contexte d exécution d un thread Java... 26 4 Réalisation de mécanismes de migration de threads Java...27 4.1 Mécanismes de migration... 27 4.1.1 Mécanisme d extraction du contexte d exécution d un thread... 27 4.1.1.1 Traitements utilisant la pile Java...27 4.1.1.2 Traitements utilisant le tas d objets...29 4.1.1.3 Traitements utilisant la zone de méthodes...29 4.1.2 Mécanisme de transfert d un contexte d exécution... 29 4.1.2.1 Traitements utilisant la pile Java...30 4.1.2.2 Traitements utilisant le tas d objets...30 4.1.2.3 Traitements utilisant la zone de méthodes...30 4.1.3 Mécanisme d intégration d un contexte d exécution à un nouveau thread... 30 4.1.3.1 Traitements utilisant la pile Java...31 4.1.3.2 Traitements utilisant le tas d objets...31 4.1.3.3 Traitements autour de la zone de méthodes...31 4.1.3.4 Lancement de l exécution du nouveau thread...31 4.2 Mécanisme d adaptation de la migration... 32 4.2.1.1 Adaptation lors de l extraction du contexte d exécution...33 4.2.1.2 Adaptation lors du transfert du contexte d exécution...33 4.2.1.3 Adaptation lors de l intégration du contexte d exécution...33 4.3 Traitement de l hétérogénéité... 33 4.3.1 Principe du traitement... 34 4.3.2 Traitement restrictif... 34 4.4 Etapes de réalisation... 34 5 Evaluation des mécanismes proposés...37 5.1 Hypothèses de base... 37

5.2 Validation des hypothèses de base... 37 5.2.1 Validation de la migration forte... 37 5.2.2 Validation de l hétérogénéité... 40 5.2.3 Validation de l adaptabilité... 40 5.2.3.1 Manipulation d objets de type Socket...40 5.2.3.2 Manipulation d objets de type Fichier...40 5.3 Utilisation des mécanismes proposés... 41 5.3.1 Agents mobiles... 41 5.3.2 Clone de thread à distance... 42 5.3.3 Sauvegarde de l état pour reprise après panne... 42 Conclusion...43 Annexe...45 Annexe 1 : Liste des instructions de byte code Java... 45 Références bibliographiques...49 Bibliographie complémentaire...53

Introduction Introduction Ce rapport présente le travail que j ai effectué durant mon stage de DEA. Je commence par introduire les motivations et les objectifs de ce stage, le projet Sirac dans lequel s est déroulé ce stage, la démarche adoptée pour aborder le problème et enfin, le plan de la suite de ce rapport. Motivations et objectifs La nécessité d équilibrer la charge de calcul et de permettre à une application de résister aux pannes a conduit des équipes de recherche universitaires et industrielles à s intéresser aux mécanismes permettant de déplacer un programme en cours d exécution d un site à un autre. Ces travaux ont abouti à la mise en œuvre de mécanismes, dits de mobilité, permettant à un processus de migrer [Barak83] [Milojicic93] ou aux objets d un langage de programmation d être déplacés [Jul88]. Cependant la mobilité est difficile à implanter. Elle pose des problèmes délicats de sécurité. Elle est coûteuse à utiliser et est peu compatible avec l hétérogénéité des sites. Enfin, elle impose des limitations au modèle d objets proposé. En conséquence le champ des applications envisagées pour l utilisation de ces techniques a longtemps été restreint, d autant plus que, la mobilité n étant pas une nécessité absolue pour répondre aux besoins des applications réparties [Chess87], peu de systèmes la permettent. Le développement d'internet et du Web a changé ces conditions et donné un nouvel essor aux travaux sur la mobilité. En effet, dans cet environnement, les performances d une application peuvent dépendre grandement de celles des communications fournies par l Internet. La latence et le débit sur l Internet étant très variables [Mukherjee94], le transfert d un processus peut non seulement apparaître comme étant d un coût raisonnable, mais peut même être considéré comme un outil d adaptation d un programme aux variations de son environnement [Ranganathan94]. Les problèmes résultant de l hétérogénéité et des difficultés d implantation sont partiellement résolus grâce à l utilisation de langages interprétés tels que Java [Arnold96], Tcl [Ousterhout94] ou Telescript [General Magic95]. C est dans ce cadre que s insère notre stage de DEA. Nos objectifs sont d'analyser les différents problèmes à résoudre pour permettre à des processus de migrer d'une machine vers une autre et d identifier les mécanismes de base qui, intégrés à la machine Java, permettraient à des processus Java de migrer d'une machine vers une autre. Les mécanismes que nous désirons fournir devront pouvoir s'adapter aux besoins des applications. Notre choix s est porté sur l extension de la machine virtuelle Java en raison, d une part, de sa grande diffusion et, d autre part, de l abstraction d un environnement homogène fournie par cette machine. 1

Introduction Cadre de travail Ce stage de DEA s est effectué au sein du projet SIRAC (Systèmes Informatiques Répartis pour Applications Coopératives) qui est un projet de l IMAG, de l INRIA (Unité de Recherche Rhône-Alpes), de l INPG, de l UJF et de l Université de Savoie. Un des axes de recherche du projet Sirac est la construction d applications réparties. L objectif de cet axe de recherche est de fournir des outils et des services pour le développement et l exécution d applications réparties. Deux directions sont actuellement explorées : Intégration et extension d applications existantes. Ce thème vise à fournir des outils permettant de construire des applications réparties par assemblage de composants existants ou de configurer ces applications à la demande et de les déployer sur des plates-formes d usage courant. Applications réparties sur l Internet. L objectif de ce thème est de fournir des services systèmes pour permettre d utiliser efficacement l Internet comme environnement d exécution d applications réparties. Les services visés en priorité concernent la gestion d objets partagés, la gestion de la sécurité et la gestion de l exécution répartie (migration du code et des données). Mes travaux de DEA se sont effectués au sein de ce dernier thème, Applications réparties sur l Internet. Ils concernent, plus précisément, la gestion de l exécution répartie et le déplacement de l exécution que nous détaillons par la suite. Démarche suivie La démarche que nous avons adoptée pour aborder le problème de la migration de processus est composée de trois étapes : L étude des travaux antérieurs concernant la migration de processus, depuis les systèmes homogènes tels que le Système V [Theimer85] jusqu aux plates-formes à agents mobiles telles que la plate-forme MOA [Milojicic98]. L étude de la structure et du fonctionnement de la machine virtuelle Java et, plus particulièrement, le traitement des flots d exécution (threads). La spécification et la réalisation d extensions de la machine virtuelle Java qui fournissent, d une part, des mécanismes de migration de processus et, d autre part, les principes de l adaptation de ces mécanismes aux besoins de l application les utilisant. Dans la dernière étape, nous avons décidé d opérer par phases successives afin de vérifier la faisabilité de chacun des mécanismes proposés. Une première phase de la réalisation a permis d interrompre un processus en cours d exécution sur une machine virtuelle Java et de créer, sur cette même machine, un nouveau processus capable, après activation, de poursuivre l exécution du premier à partir du point où il avait été arrêté. Ceci n est certes qu une étape préliminaire mais elle ouvre la voie à des mécanismes plus complets qui sont en cours de mise en œuvre. Plan du rapport Nous présentons, dans un premier temps, les travaux antérieurs concernant la migration de processus. Puis, nous décrivons les principes des mécanismes de migration de 2

Introduction processus que nous nous proposons d intégrer à la machine virtuelle Java. Pour cela, nous présentons la structure et le fonctionnement de la machine virtuelle Java. Nous décrivons, ensuite, la réalisation des mécanismes proposés et de leur évaluation. Nous concluons ce rapport en rappelant les principaux résultats obtenus et dégageons quelques perspectives ouvertes par ce travail. 3

1 La migration de processus Chapitre 1 1 La migration de processus Ce premier chapitre introduit les principes qui sont à la base de la migration de processus. Après avoir rappelé la définition des principaux concepts liés aux processus et à leur migration, nous analysons les objectifs qui motivent la migration et dressons un bref état des travaux qui la concernent. Enfin, nous essayons de dégager de l état de l art les principales difficultés rencontrées lors de la mise en œuvre des mécanismes de migration. 1.1 Définitions élémentaires Voici un rappel de certaines définitions élémentaires concernant le processus, le contexte d exécution d un processus et la migration de processus. 1.1.1 Processus et contexte d exécution Le processus est un concept clé de tous les systèmes d exploitation. La notion de processus fournit un modèle pour représenter l activité résultant de l exécution d un programme sur une machine [Krakowiak85]. Le contexte d exécution d un processus, appelé aussi état d exécution d un processus, est l ensemble des informations que les actions du processus peuvent consulter ou modifier. Le contexte d un processus résultant de l exécution d un programme varie d un système à un autre [Tanenbaum94]. En général, il comprend des informations relatives à la gestion des processus, à la gestion de la mémoire associée au processus ou à la gestion des fichiers manipulés par le processus : Gestion des processus. Les informations relatives à la gestion des processus spécifient diverses propriétés du processus telles que l identificateur du processus, la date de son lancement, son état (prêt, élu ou bloqué), le compteur de programme indiquant la prochaine instruction à exécuter et le pointeur de pile indiquant le sommet de la pile associée au processus. Gestion de la mémoire. Les informations relatives à la gestion de la mémoire sont constituées principalement du programme exécutable, des données manipulées et de la pile d exécution. Gestion des fichiers. Ces informations comprennent, par exemple, les identificateurs des fichiers manipulés par le processus. Contrairement aux processus qui forment des entités distinctes et qui ont chacun leurs ressources et leur environnement, les processus légers (threads) d un même processus partagent le même espace d adressage. 5

1 La migration de processus 1.1.2 Qu est-ce que la migration de processus La migration de processus est le déplacement d un processus en cours d exécution d une machine source vers une machine destination, ces deux machines étant reliées par un réseau de communication et n utilisant pas de mémoire partagée. La migration de processus d une machine source vers une machine destination consiste à interrompre le processus qui s exécute sur la machine source pour extraire son contexte d exécution, à transférer ce contexte vers la machine destination, à créer, sur la machine destination, un nouveau processus auquel on affectera le contexte d exécution transféré et à mettre à jour les liens de communication avec les autres processus. Une fois ceci fait, le processus sur la machine source doit être détruit tandis que le processus sur la machine destination est lancé et représente le processus déplacé. La Figure 1-1 illustre brièvement le mécanisme de migration de processus. Il existe différentes stratégies de migration de processus. Cette différence est due principalement au contexte d exécution considéré et transféré lors de la migration. En effet, le contenu du contexte d exécution transféré diffère d un mécanisme à l autre ou, plus exactement, d un degré de migration à un autre (voir section 1.4.1.1). Processus avant Transfert du contexte Processus après migration migration Machine source Machine destination Processus communiquants Figure 1-1 : Migration de processus 1.2 Motivations La migration de processus possède différents domaines d utilisation, on peut en citer quelques-uns : Disponibilité du système. Dans un système réparti, lorsque certaines machines deviennent indisponibles, les utilisateurs peuvent souhaiter que leurs applications continuent à s exécuter correctement. La disponibilité du système peut être améliorée en déplaçant les applications des machines qui sont suspectées de devenir indisponibles vers des machines encore disponibles. Administration du système. L administration de systèmes répartis peut nécessiter le déplacement de certains services d un site à un autre, lors de reconfiguration du système par exemple. Elle peut, dans certains cas, exiger la réinitialisation d une machine sans pour autant interrompre les applications en cours d exécution sur cette machine. Ces déplacements d applications peuvent être réalisés grâce au mécanisme de migration de processus. Calcul mobile. Lorsqu un utilisateur connecte son ordinateur portable à un réseau, il peut vouloir transférer une application qui est en cours d exécution, sur une station de travail 6

1 La migration de processus fixe, vers son ordinateur portable puis la retransférer vers le site d origine lors de la déconnexion de son ordinateur du réseau. Localité. Dans un système réparti, une application peut accéder à une donnée se trouvant sur un site distant ou communiquer avec une autre application se trouvant sur un site distant. Ce type d opération exige des communications et des transferts d informations à travers le réseau, ce qui peut être coûteux dans le cas d accès distants fréquents. Le déplacement de l application vers le site où se trouve la donnée utilisée ou vers le site où se trouve l application avec laquelle elle communique transforme les accès à travers le réseau en accès locaux et réduit ainsi le temps d exécution de l opération souhaitée. Partage de ressources. Grâce à la migration, un processus peut se déplacer, en cours d exécution, vers un site distant et profiter ainsi des ressources physiques de ce site telles que la mémoire ou le disque dur. Il peut aussi profiter de la ressource CPU dans le cas de la répartition dynamique de charge. En effet, pour qu un processus ait le plus de temps CPU possible, il faut qu il s exécute sur la machine qui fournit le plus de capacité de calcul. Les machines les plus rapides et les machines les moins chargées sont les plus intéressantes. Dans un système réparti, la migration permet à un processus de profiter des ressources du système qui sont sous-utilisées, en le déplaçant vers la machine appropriée. 1.3 Algorithme général de migration de processus Il existe différentes techniques de réalisation du mécanisme de migration de processus mais la plupart de ces techniques passent par les principales étapes suivantes [Milojicic97] : 1. Le processus est détaché du site source en suspendant son exécution et en suspendant momentanément ses communications. 2. Le contexte d exécution du processus est extrait, le contenu de ce contexte étant dépendant de la stratégie de migration choisie (voir section 1.4.1.1). 3. Un nouveau processus est créé sur le site destination ; le contexte d exécution extrait sera ultérieurement affecté à ce processus et ce processus représentera le processus déplacé. 4. La communication est redirigée en renvoyant les messages au nouveau processus pour que ceux-ci soient traités après la migration. 5. Le contexte d exécution extrait est envoyé au nouveau processus pour y être intégré. Pour des raisons de performance, certaines mécanismes de migration n exigent pas le transfert de tout le contexte d exécution avant la fin de la migration. La technique COR (Copy-On-Reference) [Zayas87] et la technique de pré-copie [Theimer85] sont de telles techniques. Le principe de la technique COR est de ne transférer les pages mémoire appartenant au contexte d un processus qu au moment où celles-ci sont référencées par le processus déplacé. Ceci permet de réduire la durée de transfert du contexte d un processus mais augmente le temps d exécution après migration puisqu il y a traitement des fautes de pages. La technique de pré-copie, quant à elle, a pour principe de transférer vers le site destination l espace d adressage du processus avant la migration de celui-ci, ce qui permet de réduire le temps de traitement de la migration. 6. Le nouveau processus continue l exécution dès que la partie de son contexte nécessaire à son exécution est reçue. A partir de ce moment, la migration prend fin. Une partie du contexte du processus sur le site source peut être maintenue, dans le cas d un transfert retardé ; une fois tout le contexte transmis, le processus sur le site source peut être définitivement arrêté. 7

1 La migration de processus 1.4 Travaux antérieurs Dans cette partie, nous établissons, tout d abord, une classification des différents travaux réalisés dans le domaine de la migration de processus. Nous présentons ensuite certains mécanismes servant d alternatives au mécanisme de migration de processus. Car pour des raisons de complexité de réalisation du mécanisme de migration ou pour des raisons de coût d une opération de migration de processus, il peut être préférable d utiliser un autre mécanisme représentant une alternative au mécanisme de migration de processus et moins coûteux que celui-ci. 1.4.1 Classification des travaux sur la migration de processus Différentes recherches ont été menées dans le cadre de la migration de processus et différents systèmes expérimentaux ont été réalisés. Une étude des principales techniques développées dans le domaine peut être trouvée dans [Nuttall94]. Ces travaux peuvent être classés selon plusieurs critères tels que le degré de la mobilité, l hétérogénéité du système ou la portabilité du mécanisme de migration réalisé. Nous détaillons, ci-dessous, chacun de ces trois critères. 1.4.1.1 Degrés de mobilité Il existe différents degrés de mobilité : l exécution à distance et le code à la demande, la migration faible et la migration forte. La Figure 1-2 illustre brièvement ces différents degrés de mobilité. déplacement du code et déplacement du code et déplacement du code, des données initiales des données courantes des données courantes et de l état d exécution mobilité Exécution à distance Code à la demande Mobilité du code Migration faible Migration forte Migration Figure 1-2 : Degrés de mobilité Dans le cas de l exécution à distance, une exécution de programme qui n a pas encore commencé est transférée vers un site distant. Dans ce cas, les informations transférées lors du déplacement sont principalement le code à exécuter et les valeurs initiales des données manipulées. Il n y a pas de transfert des valeurs courantes des données (appelées état des données) ni de l état d exécution d un processus puisque le déplacement se fait avant le début de l exécution (pas de processus créé sur la machine d origine). L exécution à distance est basée sur le mécanisme de RPC (appel de procédure à distance) [Birrell84]. Le système Utopia [Zhou94] a utilisé une telle exécution et le projet Tacoma [Johansen95] a réalisé une plate-forme à agents mobiles en Tcl/Tk fournissant ce type de mobilité pour ses agents. 8

1 La migration de processus Contrairement à l exécution à distance, où c est généralement le site source qui décide de transférer une exécution vers le site destination, le code à la demande permet au site destination de ramener un code et ses données initiales du site source pour qu il s exécute sur le site destination. Les Applets Java [Sun94] utilisent un tel mécanisme. La migration faible permet d interrompre un processus, en cours d exécution, sur un site source, de transférer son code et l état courant de ses données vers la machine destination et de reprendre son exécution sur la machine destination. Il est important de noter qu après une telle migration, l exécution du code sur la machine destination reprend depuis le début tout en tenant compte des nouvelles valeurs des données. Les Aglets [IBM96] sont des agents mobiles dont la mobilité est réalisée par migration faible. La migration forte, quant à elle, permet de transférer non seulement le code et l état des données du processus à déplacer, mais aussi l état d exécution de ce processus, ce qui permet de reprendre l exécution de ce dernier, sur le site destination, au point même où il a été interrompu. Sumatra [Ranganathan97] et MAP [Perret97] sont des plates-formes à agents mobiles fournissant une telle mobilité pour leurs agents. 1.4.1.2 Hétérogénéité Considérons maintenant l aspect hétérogénéité. Les premiers travaux réalisés dans le cadre de la migration de processus ont été faits dans des systèmes homogènes (des systèmes dont les machines sont de même architecture). DEMOS/MP [Powell83] est l un des premiers systèmes réalisant la migration de processus ; c est un système implanté sur des machines homogènes. Les recherches menées dans le domaine se sont ensuite intéressées à la réalisation de la migration de processus dans des systèmes hétérogènes. La complexité d une telle réalisation dépend, en particulier, du fait que la représentation de l état d exécution d un processus soit dépendante ou indépendante de la machine (la représentation d une information est dépendante de la machine si cette représentation change d une architecture à une autre). Dans le cas où la représentation de l état d exécution d un processus est dépendante de la machine, comme pour le code natif par exemple, réaliser la migration d un processus sur des machines hétérogènes revient à effectuer des traductions entre des représentations différentes de l état du processus pour le transfert de celui-ci d une machine à une autre. Emerald [Steengaard95] et Tui [Smith96] sont des systèmes qui proposent des mécanismes de migration de processus entre machines hétérogènes. Dans le cas où la représentation de l état d exécution d un processus est indépendante de la machine, comme pour le code interprété par exemple, la réalisation d un mécanisme de migration de processus dans un système hétérogène devrait être la même que celle de la migration dans un système homogène. 1.4.1.3 Portabilité Intéressons-nous à présent à un autre critère qui est le critère de portabilité. Les travaux de recherche menés dans le cadre de la migration de processus ont suivi deux voies principales : réalisation du mécanisme de migration dans un système existant ou implémentation d un nouveau système fournissant, entre autres fonctionnalités, la migration de processus. La première voie consiste à réaliser un mécanisme de migration de processus audessus d un système existant et répandu, sans modifier ce dernier, ce qui permet d assurer la portabilité du mécanisme de migration fourni. Les travaux réalisés par Freedman [Freedman91] ont suivi cette politique, en fournissant un mécanisme de migration de processus au-dessus du système UNIX. La seconde voie consiste à réaliser un nouveau système qui fournit, entre autres mécanismes, la migration de processus. Cette solution permet de réaliser une migration plus 9

1 La migration de processus complète du processus. Elle présente tout de même l inconvénient de réduire l utilisation du mécanisme de migration proposé car celui-ci n est pas fourni dans un système standard et répandu. Les systèmes Sprite [Douglis91] et V [Theimer85] suivent cette politique. 1.4.2 Alternatives à la migration de processus La réalisation d un mécanisme de migration peut être relativement complexe et une opération de migration de processus peut être coûteuse. Pour remédier à ce problème, d autres solutions ont été explorées [Milojicic97]. Ces autres mécanismes, que nous allons présenter maintenant, offrent une alternative à la migration de processus. 1.4.2.1 Processus clone Un processus père peut créer un processus fils qui est son propre clone et qui hérite de son état ; ceci peut être fait grâce au mécanisme de fork. Un fork à distance, suivi d un arrêt du processus père, ressemble tout à fait à une migration de processus. Ce mécanisme de fork à distance a été utilisé dans plusieurs systèmes tels que le système UNIX proposé par Zajcew [Zajcew93]. Mais la complexité et le coût d une telle opération sont similaires à ceux d une opération de migration de processus. 1.4.2.2 Agents mobiles et langages sûrs et interprétés Les agents mobiles deviennent de plus en plus populaires dans l environnement du Web [Berners-Lee94]. La mobilité dans le Web implique des problèmes de sécurité plus que des problèmes de performances puisque celles-ci sont masquées par le coût des communications dans un réseau à grande distance. Les agents mobiles sont réalisés au-dessus de langages sûrs et interprétés tels que les langages Java [Arnold96], Telescript [General Magic95] ou Tcl/Tk [Ousterhout94]. Dans des systèmes à agents mobiles tels que Mole [Baumann96] écrit en Java, Telescript ou AgentTcl [Gray96] écrit en Tcl/Tk, le problème d hétérogénéité est masqué grâce au langage interprété utilisé. 1.5 Problèmes rencontrés lors de la réalisation de la migration de processus Les principaux problèmes rencontrés lors de la mise en œuvre d un mécanisme de migration de processus concernent l hétérogénéité du système, le maintien de la validité des canaux ouverts utilisés par un processus et le maintien des communications entre processus lors de la migration d un processus. Nous détaillons ci-dessous chacun de ces problèmes. 1.5.1 Hétérogénéité La réalisation d un mécanisme de migration de processus dans un système de machines hétérogènes présente une difficulté particulière dans le cas où la représentation du code et des données du processus est dépendante de la machine sur laquelle s exécute ce processus. Dans ce cas, la représentation de l état d un processus sur une machine source n est pas comprise par la machine destination si celle-ci n est pas de la même architecture que la première. Il existe deux solutions principales pour remédier à ce problème. Soit l état du processus est traduit directement de la représentation du site source vers la représentation du site destination ; et dans ce cas, il faut autant de traducteurs qu il existe de couples d architectures différentes. Soit l état du processus est représenté dans un format 10

1 La migration de processus intermédiaire, indépendant de la machine et compris par toutes les machines ; et dans ce cas, il faut deux traductions pour chaque transfert d état. Le mécanisme de migration fourni par le système Emerald [Steengaard95] utilise un format intermédiaire pour représenter l état du processus à déplacer. 1.5.2 Maintien de la validité des canaux ouverts Un autre problème rencontré lors de la réalisation d un mécanisme de migration de processus concerne le maintien de la validité des canaux ouverts utilisés par un processus qui se déplace. Nous appelons canal ouvert toute entité qui est dépendante du système sous-jacent et qui n est plus valide dans un autre système. Un canal ouvert peut être un descripteur de fichier, un canal de communication (socket), un sémaphore, une file d attente ou une zone mémoire partagée. Que se passe-t-il lorsqu un processus qui s exécute sur une machine source et qui accède à un fichier local à cette machine, se déplace vers une machine destination où il doit continuer à accéder à ce fichier? Le descripteur de fichier, utilisé par le processus sur la machine source, n a plus de sens sur la machine destination. Le même problème se pose avec les autres types de canaux ouverts. Une solution à ce problème est de garder des liens de poursuite entre les sites par lesquels passe un processus qui se déplace. Ces liens de poursuite permettent à un processus, déplacé d une machine source vers une machine destination, d accéder depuis la machine destination au canal ouvert se trouvant sur la machine source (par accès distant). Ainsi, le processus déplacé peut accéder à distance à un fichier. Cette solution n est pas applicable dans le cas où une panne peut survenir sur le site source ou sur la liaison réseau entre le site source et le site destination, car les liens de poursuite ne sont alors plus valides. Une autre solution à ce problème est de fournir une identification universelle des canaux ouverts ; avec une telle solution, un même canal ouvert possède le même identificateur sur toutes les machines. Le système Charlotte [Artsy89], qui fournit un mécanisme de migration de processus, fournit aussi un système de gestion de fichiers répartis et donc, une identification universelle des fichiers dans ce système. Un autre exemple d utilisation de cette technique est le micro-noyau Chorus [Rozier88] où un mécanisme de migration de processus est fourni [O Connor93] et où une identification universelle des canaux de communication (appelés ports) est réalisée. 1.5.3 Maintien des communications entre processus Le maintien des communications entre processus est un autre problème rencontré lors de la migration de processus. En effet, que se passe-t-il lorsqu un message arrive à un processus alors que celui-ci est en cours de migration? Ces messages risquent d être perdus si aucun traitement spécifique n est fait. Une solution à ce problème est de considérer que le processus qui est en cours de migration est dans un état particulier, où il n accepte pas de messages provenant d autres processus. Dans ce cas, avant le déplacement d un processus, les processus communiquant avec lui doivent être mis au courant pour ne pas envoyer de message au cours de la migration. Une autre solution est de retarder momentanément l acheminement des messages au processus destinataire, le temps que celui-ci ait terminé sa migration ; les messages lui seront ensuite renvoyés vers sa nouvelle localisation. 11