Mécanismes pour la migration de processus

Transcription

1 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 Grenoble cedex 9 Tel. : Fax :

2

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

4

5 Mécanismes pour la migration de processus Extension de la machine virtuelle Java Sommaire Introduction La migration de processus Définitions élémentaires Processus et contexte d exécution Qu est-ce que la migration de processus Motivations Algorithme général de migration de processus Travaux antérieurs Classification des travaux sur la migration de processus Degrés de mobilité Hétérogénéité Portabilité Alternatives à la migration de processus Processus clone Agents mobiles et langages sûrs et interprétés Problèmes rencontrés lors de la réalisation de la migration de processus Hétérogénéité Maintien de la validité des canaux ouverts Maintien des communications entre processus Conception de mécanismes de migration de processus dans Java Objectifs de la réalisation Contexte de réalisation Le langage Java Un langage orienté-objet Un langage interprété La machine virtuelle Java Positionnement par rapport aux travaux antérieurs Problèmes et solutions Principes des mécanismes de migration à réaliser... 17

6 3 Machine Virtuelle Java Introduction Présentation générale Exemple introductif Structure de la machine virtuelle Java Zones de données d exécution Le registre pc La pile Java Le tas La zone de méthodes Le constant pool Les piles de méthodes natives Frames Les variables locales Les piles d opérandes La liaison dynamique Fonctionnement de la machine virtuelle Java Démarrage de la machine virtuelle Chargement Liaison Initialisation Terminaison de la machine virtuelle Threads Java Structure du contexte d exécution d un thread Java Réalisation de mécanismes de migration de threads Java Mécanismes de migration Mécanisme d extraction du contexte d exécution d un thread Traitements utilisant la pile Java Traitements utilisant le tas d objets Traitements utilisant la zone de méthodes Mécanisme de transfert d un contexte d exécution Traitements utilisant la pile Java Traitements utilisant le tas d objets Traitements utilisant la zone de méthodes Mécanisme d intégration d un contexte d exécution à un nouveau thread Traitements utilisant la pile Java Traitements utilisant le tas d objets Traitements autour de la zone de méthodes Lancement de l exécution du nouveau thread Mécanisme d adaptation de la migration Adaptation lors de l extraction du contexte d exécution Adaptation lors du transfert du contexte d exécution Adaptation lors de l intégration du contexte d exécution Traitement de l hétérogénéité Principe du traitement Traitement restrictif Etapes de réalisation Evaluation des mécanismes proposés Hypothèses de base... 37

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

8

9 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

10 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

11 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

12

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

14 1 La migration de processus 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 ). 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

15 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 ). 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

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

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

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

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

20

21 2 Conception de mécanismes de migration de processus dans Java Chapitre 2 2 Conception de mécanismes de migration de processus dans Java Ce chapitre présente les concepts des mécanismes de migration de processus à réaliser dans Java. Il rappelle, tout d abord, les objectifs de la réalisation. Il présente ensuite le contexte de cette réalisation sous différents aspects : d une part, Java en tant que langage orienté-objet, langage interprété et machine virtuelle et, d autre part, un positionnement de cette réalisation par rapport au travaux antérieurs et les solutions apportées aux principaux problèmes rencontrés. Il décrit enfin les principes généraux des mécanismes de migration de processus à réaliser. 2.1 Objectifs de la réalisation Nous rappelons ici les objectifs de ce stage de DEA. Ces objectifs sont l extension de la machine virtuelle Java pour qu elle fournisse, d une part, les mécanismes nécessaires à la migration de processus et, d autre part, des mécanismes permettant de spécialiser la migration de processus en fonction des besoins de l application visée. Pour ce qui est des mécanismes nécessaires à la migration de processus, ceux-ci concernent principalement : l opération d extraction du contexte d exécution courant d un processus, l opération de transfert d un contexte d exécution d une machine à une autre et l opération de création d un processus en y intégrant un certain contexte d exécution. Quant aux mécanismes de spécialisation de la migration de processus, ils visent l adaptation de la migration aux besoins de l application l utilisant. Nous ne proposons pas ici un ensemble de mécanismes d adaptation de la migration mais des principes d adaptation de la migration. Une application peut mettre en œuvre ces principes pour spécialiser les traitements effectués sur certains types d objets manipulés par un processus, lors de la migration de celui-ci. Un exemple de cette spécialisation est de décider que les fichiers manipulés par un processus et qui sont locaux au site où se trouve ce processus seront manipulés, après migration du processus, par accès distant. Un autre exemple est celui des canaux de communication (sockets) ouverts utilisés par un processus. Un traitement spécifique de ce type d objet, lors de la migration de processus, est de décider de fermer ces canaux de communication, d en ouvrir de nouveaux sur la nouvelle localisation du processus et de rétablir les connexions. 13

22 2 Conception de mécanismes de migration de processus dans Java L objectif de ce travail n est pas de fournir un mécanisme de migration de processus figé mais de fournir des outils de base permettant de réaliser la migration de processus et de la spécialiser pour qu elle réponde au mieux aux besoins des applications l utilisant. 2.2 Contexte de réalisation Cette partie présente le contexte de réalisation des mécanismes proposés pour la migration de processus dans Java. Une brève présentation de Java en tant que langage orientéobjet, langage interprété et machine virtuelle est présentée, suivie d un positionnement de la réalisation proposée par rapport aux travaux antérieurs Le langage Java Voici une brève présentation du langage Java en tant que langage orienté-objet et langage interprété et une brève introduction à la machine virtuelle Java Un langage orienté-objet La programmation orientée-objet repose sur un concept simple et naturel qui est l objet. Un objet est une entité regroupant, d une part, une structure de donnée et, d autre part, les opérations associées à cette structure de données. La structure de données représente les caractéristiques qui sont propres à un objet et les opérations définissent les traitements applicables à cet objet. Les objets d une classe sont les objets qui ont une même structure et un même comportement. Une étude des propriétés essentielles de cette approche peut être trouvée dans [Wegner87] et [Atkinson91]. Le langage java est un langage orienté-objet, proposant plusieurs classes d objets, en particulier, la classe Thread à laquelle nous nous intéresserons plus particulièrement Un langage interprété Voici un bref rappel des différents types de codes existants. Il y a tout d abord le code binaire, appelé aussi code machine ou code exécutable [Galler62]. Le format de ce code est dépendant de la machine, il est donc exécuté directement sans passer par une phase de compilation ni subir d opération d interprétation. Il y a ensuite le code source dont le format est indépendant de la machine. Un tel code peut être de deux catégories que nous appelons code interprétable (ou interprété) et code compilable. Le code interprétable est traduit, au fur et à mesure de son exécution, d un format indépendant de la machine vers un format dépendant de la machine ; cette opération est appelée interprétation. Le byte code Java [JDK1.1.3], le P-Code [Nelson79] et les codes écrits dans des langages tels que Perl [Wall97] ou Tcl/Tk [Ousterhout94] sont de tels codes. Le code compilable, quant à lui, doit tout d abord passer par une phase de compilation, générant ainsi soit du code machine soit du code interpétable. Les codes écrits dans des langages tels que les langages C [Garreta92] et ADA [Barnes91] génèrent du code machine après compilation. Tandis que les codes écrits dans des langages tels que le langage Java [Campione96] ou le langage Pascal [Le Beux80] (pour un compilateur Pascal particulier) génèrent du code interprétable. La Figure 2-1 résume les différents types de codes. 14

23 2 Conception de mécanismes de migration de processus dans Java Le langage Java est un langage interprété. La compilation d un programme source Java génère du code à interpréter (byte code), ce code interprété étant un format intermédiaire entre le format source Java et le format binaire exécutable. De ce fait, un programme Java compilé est indépendant de la machine ; il peut s exécuter sur tout type de machine, pourvu qu il y ait un interprète Java sur cette machine. Et avec le déploiement du Web, cette caractéristique a rendu Java plus populaire, permettant de déplacer un même code Java compilé d une machine à une autre à travers l Internet. compilation Code source compilable Code source compilable compilation Code source interpétable Code binaire Code interpétable a) Code source à compiler b) Code source à compiler c) Code source à puis exécuter puis interpéter interpéter Figure 2-1 : Types de codes La machine virtuelle Java La machine virtuelle Java est un processeur logiciel dont le langage machine est le byte code. Elle possède, de ce fait, un ensemble d instructions de byte code et manipule un ensemble de registres lors de l exécution d un code. Parmi les instructions de byte code, nous pouvons citer les instructions arithmétiques, les instructions de chargement et de sauvegarde. Quant aux registres manipulés par la machine virtuelle, ils seront abordés plus en détail par la suite, dans la section 3.2 ; mais nous pouvons tout de même en citer quelques-uns uns tels que le registre de base indiquant le début de la pile d exécution ou le pointeur de programme indiquant la prochaine instruction à exécuter. Code source Java Compilation Byte code Java JVM JVM JVM Archi. 1 Archi. 2 Archi. n Fifure 2-2 : Java et l hétérogénéité 15

24 2 Conception de mécanismes de migration de processus dans Java Il est important de rappeler que le byte code est un format de code indépendant de l architecture de la machine sous-jacente ; il en résulte qu une même suite d instructions de byte code peut être exécutée par des machines virtuelles Java installées sur différentes architectures. De ce fait, la machine virtuelle Java fournit l abstraction d une seule et même machine, indépendante de l architecture sous-jacente ; et permet ainsi de considérer un ensemble de machines hétérogènes comme un système homogène. La Figure 2-2 illustre le principe d homogénéisation de la machine virtuelle Java (JVM) Positionnement par rapport aux travaux antérieurs Nous proposons ici un positionnement des mécanismes de migration de processus proposés par rapport aux travaux antérieurs et, plus précisément, par rapport aux trois critères de classification présentés à la section et qui sont : le degré de mobilité du code, l hétérogénéité du système et la portabilité du mécanisme de migration réalisé. La migration de processus que nous nous proposons de fournir est une migration forte. Elle transfère le code, l état des données manipulées par le processus et l état d exécution du processus, permettant à celui-ci de reprendre son exécution, après migration, au point même où elle a été interrompue. Notre choix s est porté sur la migration forte car, pour les processus, ce type de migration est le plus complet. D autre part, les mécanismes de migration de processus proposés sont dotés du critère de portabilité défini dans la section En effet, ces mécanismes de migration sont intégrés à un système déjà existant qui est la machine virtuelle Java. Donc, tout système pourvu de cet interprète Java étendu et, plus particulièrement du JDK de Sun [JDK1.1.3] étendu, pourra utiliser les mécanismes de migration proposés. Notre choix s est porté sur l extension d un système déjà existant et répandu pour qu il fournisses de nouveaux mécanismes. Pour ce qui est du critère d hétérogénéité, la machine virtuelle Java que nous avons étendue et qui est le JDK de Sun est dédiée à plusieurs plates-formes telles que les systèmes Solaris sur architecture Sparc, Solaris sur architecture de type x86, Microsoft Windows NT et Microsoft Windows 95. Les mécanismes de migration de processus proposés sont donc dédiés à un système de machines hétérogènes, leur fournissant ainsi une plus large diffusion Problèmes et solutions Les principaux problèmes rencontrés lors de l implantation d un mécanisme de migration de processus ont été décrits dans la section 1.5. Ils concernent principalement l hétérogénéité du système, le maintien de la validité des canaux ouverts manipulés par un processus et le maintien des communications entre processus lors de la migration d un processus. En ce qui concerne le problème d hétérogénéité des machines, dans notre cas, il est simplifié, voire supprimé. En effet, du fait que la représentation de l état d exécution d un processus soit la même pour toutes les plates-formes supportées par la machine virtuelle Java, la réalisation du mécanisme de migration de processus dans un système hétérogène est similaire à une réalisation dans un système homogène. Quant aux problèmes de maintien de validité des canaux ouverts et de maintien des communications entre processus après migration, ils ne sont pas abordés à notre niveau. En effet, nous ne voulons pas proposer une solution unique et figée. Nous laissons donc, à l application utilisant nos mécanismes, le choix de mettre en œuvre les techniques qui répondent au mieux à ses besoins. 16

25 2 Conception de mécanismes de migration de processus dans Java 2.3 Principes des mécanismes de migration à réaliser Pour fournir les mécanismes nécessaires à la migration de processus dans Java, il faut étendre la machine virtuelle Java. Cette extension se fait en rajoutant, à une classe particulière de Java qui est la classe Thread, certains attributs définissant de nouvelles caractéristiques et certaines méthodes définissant de nouveaux traitements sur les objets de la classe Thread de Java. L extension est faite précisément dans la classe Thread car cette classe décrit les objets Java qui sont susceptibles d engendrer un nouveau flot d exécution. Une description de l interface originelle de la classe Thread fournie par JDK peut être trouvée dans [JDK1.1.3]. L extension proposée a pour objectif de fournir de nouvelles caractéristiques et de nouveaux traitements à la classe Thread, permettant d y intégrer des mécanismes de migration de threads Java. Nous nous proposons d intégrer à la classe Thread plusieurs méthodes : Une première méthode qui permet de suspendre un thread Java et d extraire son contexte d exécution courant. Une autre méthode qui transfère le contexte d exécution et les objets manipulés par un thread d un site à un autre. Et une dernière méthode qui, à partir d un contexte d exécution donné, crée un nouveau thread Java, y intègre le contexte considéré et lance le thread pour qu il poursuive l exécution. Un autre objectif de l extension proposée est de fournir une migration spécialisée, une migration qui ne transfère pas automatiquement tous les objets manipulés par un thread mais effectue un traitement spécifique en fonction de leurs types. Pour mettre ceci en œuvre, deux types traitements sont nécessaires : Avant le transfert des objets manipulés par un thread, il faut effectuer des traitements spécifiques en fonction des types de ces objets. Ceci peut correspondre, par exemple, à fermer les objets de type socket avant de transférer les objets à partir de la machine source. A la réception des objets sur la machine destination, il faut effectuer des traitements d initialisation spécifiques aux types d objets. Ceci peut correspondre, par exemple, à ouvrir les objets de type socket pour rétablir les liaisons de communication. Nous avons donc présenté les principes généraux des mécanismes proposés pour fournir la migration de threads Java. La réalisation de ces mécanismes sera abordée, de façon plus détaillée, dans le Chapitre 4. L extension présentée ici est faite dans la classe Thread de Java. Mais nous proposerons une autre extension en section

26

27 3 Machine Virtuelle Java Chapitre 3 3 Machine Virtuelle Java Ce chapitre présente la Machine Virtuelle Java. Il introduit le rôle de la machine virtuelle, décrit sa structure générale, retrace son cycle de vie et explique son fonctionnement lors de la manipulation de threads Java. 3.1 Introduction Cette partie introduit le rôle de l interprète Java et illustre son fonctionnement par un exemple introductif Présentation générale La compilation d un programme source Java produit une suite d instructions de byte code stockées dans un fichier particulier ayant pour nom le nom du fichier contenant le programme source auquel est ajouté le suffixe class. Le lancement de l exécution d un fichier.class provoque la création d un processus dont le rôle est de parcourir la suite d instructions de byte code stockée dans le fichier.class et d interpréter, au fur et à mesure, chacune de ces instructions. La Figure 3-1 illustre ce mécanisme. Compilation Prog. source Java Machine Virtuelle Java Byte code Java Une instruction de byte code Interprète Java Une suite d instructions machine Machine physique Exécution des instructions machine Figure 3-1 : Interprète Java 19

28 3 Machine Virtuelle Java Exemple introductif Pour introduire le mécanisme d interprétation, nous nous proposons de prendre un exemple de programme source Java que nous compilons pour générer le byte code associé. La Figure 3.2 donne un exemple simple de programme source Java et la Figure 3-3 présente les instructions de byte code qui lui sont associées. class Test { int val ; public Test (int val_init) { } this.val = val_init ; public void plus ( ) { } this.val ++ ; public static void main (String args[ ]) { Test t ; } } t = new Test (5) ; t.plus () ; Method Test (int) 0 aload_0 1 invokespecial #3 <Method Object( )> 4 aload_0 5 iload_1 6 putfield #6 <Field int val> 9 return Method void plus ( ) 0 aload_0 1 dup 2 getfield #6 <Field int val> 5 iconst_1 6 iadd 7 putfield #6 <Field int val> 10 return Method void main (java.lang.string[ ]) 0 new #1 <Class Test> 3 dup 4 iconst_5 5 invokespecial #4 <Method Test(int)> 8 astore_1 9 aload_1 10 invokevirtual #5 <Method void plus( )> Figure 3-2 : Exemple de code source Java Figure 3-3 : Exemple de byte code Java Le code source Java, proposé dans la Figure 3-2, déclare une classe Test (une sousclasse directe de la classe mère Object de Java). Cette classe possède un attribut entier de nom val, une méthode particulière qui est le constructeur Test permettant d initialiser l attribut val lors de la création d une nouvelle instance de cette classe, une méthode de nom plus permettant d incrémenter la valeur de l attribut val, et une méthode particulière qui est la méthode main exécutée lors du lancement de ce programme. Cette dernière méthode déclare un objet Java de type Test, crée une nouvelle instance de la classe Test en initialisant son attribut val à 5 et appelle la méthode plus sur cette instance créée. Après compilation de ce programme source Java, nous obtenons la suite d instructions de byte code présentée dans la Figure 3-3. Cette figure présente, pour chaque méthode de la classe Test, la suite d instructions de byte code correspondant. Pour chacune de ces méthodes, une liste de couples de numéro et d instruction de byte code est générée. Une instruction est composée d un code opération (opcode) représenté sur un octet et d éventuels opérandes représentés sur zéro ou plusieurs octets. Le numéro précédant une instruction de byte code, dans la Figure 3-3, représente l indice du premier octet de cette instruction dans le tableau d octets contenant la suite d instructions de la méthode considérée. Nous remarquons, par exemple, que la troisième instruction de la méthode de nom Test est indicée à 4 ; ceci vient du 20

29 3 Machine Virtuelle Java fait que la première instruction de cette méthode est codée sur un octet et que la deuxième instruction est codée sur trois octets, ce qui fait un décalage de quatre octets. Considérons à présent la méthode main et intéressons-nous à certaines de ses instructions. La première instruction de byte code, qui est l instruction new, a pour opérande la classe Test. Son rôle est de créer une nouvelle instance de la classe Test. L instruction invokespecial a pour opérandes la méthode d initialisation Test et l entier 5 (préalablement empilé sur la pile d exécution grâce à l instruction iconst_5). Le rôle de cette instruction est d appeler une méthode d initialisation d instance. Quant à l instruction invokevirtual, elle a qui a pour opérande la méthode plus et son rôle est d appeler cette dernière méthode. Nous avons donc présenté un exemple de byte code et le rôle de certaines de ses instructions. Une liste plus complète des instructions de byte code Java est proposée en Annexe Structure de la machine virtuelle Java Cette partie présente la structure de la machine virtuelle Java. Elle définit, tout d abord, les zones de données utilisées lors de l exécution, ces données regroupant le compteur de programme pc, la pile d exécution Java, le tas, la zone de méthodes Java, la table des symboles constant pool et les piles des méthodes natives. Elle définit ensuite la structure frame, cette zone mémoire rattachée à une méthode appelée ; et présente certaines des structures de données qui lui sont rattachées telles que la table des variables locales et la pile des opérandes ou le mécanisme de liaison dynamique Zones de données d exécution Voici une présentation des différentes données utilisées par la machine virtuelle Java, lors d une exécution Le registre pc La machine virtuelle Java peut supporter l exécution de plusieurs threads à la fois. A tout moment, un thread de la machine virtuelle Java exécute le code d une seule méthode, la méthode courante de ce thread. Chaque thread de la machine virtuelle Java possède son propre registre pc (compteur de programme). Si la méthode courante du thread n est pas native (son code est indépendant de la plate-forme sous-jacente), le registre pc contient l adresse de la prochaine instruction de byte code à exécuter. Mais si cette méthode est native, la valeur du registre pc est indéfinie. Dans ce cas, le contexte du thread n est pas observable dans la machine virtuelle Java La pile Java Tout thread de la machine virtuelle Java possède sa propre pile Java, créée lors de la création de ce thread. La pile Java est équivalente à la pile d exécution utilisée dans un langage conventionnel tel que le langage C : elle permet la sauvegarde des variables locales et des résultats intermédiaires et elle sert à empiler les appels de méthodes imbriquées Le tas La machine virtuelle Java possède une zone mémoire partagée par tous les threads et appelée tas. Le tas sert à l allocation dynamique de zones mémoire pour les instances de classes et les tableaux Java. 21

30 3 Machine Virtuelle Java La zone de méthodes La machine virtuelle Java possède une zone de méthodes partagée par tous les threads. La zone de méthodes Java est similaire à une zone de stockage de code compilé dans un langage conventionnel ou au segment text d un processus UNIX. La zone de méthodes contient, pour chaque classe, le code de ses méthodes et de ses constructeurs Le constant pool Chaque classe et chaque interface Java possède une structure de données appelée constant pool. Le constant pool est équivalent à une table de symboles dans un langage conventionnel ; c est un tableau qui contient différentes sortes de constantes telles que les constantes de type numérique connues à la compilation ou les références vers des méthodes ou des attributs résolues au moment de l exécution Les piles de méthodes natives Pour les méthodes natives, écrites dans d autres langages que le langage Java, la machine virtuelle Java utilise des piles conventionnelles appelées piles C. Si la machine virtuelle Java supporte l exécution de méthodes natives, une pile C est allouée à chaque thread créé Frames Les frames de la machine virtuelle Java sont des zones mémoire servant à stocker les données, les résultats partiels, les valeurs de retour de méthodes et à effectuer la liaison dynamique (section ). Un frame Java est similaire à un bloc de procédure dans les langages conventionnels. Un nouveau frame est créé à chaque appel de méthode et il est détruit lorsque la méthode associée se termine. Un frame est alloué dans la pile Java du thread créant ce frame. Chaque frame possède ses propres variables locales (section ) et sa propre pile d opérandes (section ). Pour chaque thread, un seul frame est actif à la fois : le frame de la méthode en cours d exécution. Ce frame est appelé frame courant, la méthode associée est appelée méthode courante et la classe à laquelle appartient cette méthode est appelée classe courante. Un frame cesse d être actif si sa méthode appelle une autre méthode ou si sa méthode se termine. Lorsqu une méthode est appelée, un nouveau frame est créé et empilé sur la pile Java, ce nouveau frame devient le frame courant et sa méthode la méthode courante. A la fin de la méthode courante, le frame courant retourne le résultat de sa méthode au frame précédent. Le frame courant est ensuite supprimé (dépilé) et le frame qui le précède devient le frame courant Les variables locales A chaque appel d une méthode Java, la machine virtuelle Java alloue un nouveau frame qui contient une zone mémoire particulière qui est la table des variables locales de cette méthode. Les variables locales d une méthode Java comprennent aussi les paramètres de la méthode. Cette table de variables locales, manipulée par la machine virtuelle Java, est similaire aux registres et aux zones mémoire de la pile d exécution, manipulés par une machine physique, et servant à stocker les variables locales et les paramètres des procédures, comme c est le cas pour l assembleur [Jaulent83]. 22

31 3 Machine Virtuelle Java Les piles d opérandes Un frame contient une zone mémoire particulière qui est la pile d opérandes. Cette pile sert à stocker les résultats intermédiaires (opérandes) des fonctions calculées. Elle sert aussi à passer les arguments d une méthode appelée et à recevoir le résultat d une méthode La liaison dynamique Un frame contient une référence vers le constant pool associé à la classe ou l interface de la méthode de ce frame. Cet accès au constant pool permet d effectuer la liaison dynamique du code de la méthode. Dans le code d une méthode, il peut y avoir des références symboliques vers des méthodes à appeler ou des variables à manipuler. Ces références symboliques sont traduites, au cours de l exécution, en références directes grâce à la liaison dynamique, allant jusqu à charger les classes référencées et manquantes. Frame 2 pile d opérandes méthode courante constant pool pc Variables locales zone des méthodes de la classe constant pool de la classe Frame 1 pile d opérandes méthode courante constant pool pc zone des méthodes de la classe constant pool de la classe variables locales Légende Pile Java Info.s complémentaires pour la pile Java. Info.s complémentaires pour un frame. Figure 3-4 : Structure de la JVM 23

32 3 Machine Virtuelle Java La Figure 3-4 illustre la structure de la Machine Virtuelle Java (JVM) lors de l exécution d un programme Java. L image d exécution proposée ici montre que le frame courant est le Frame 2 et que la méthode courante est donc la méthode associée à ce frame. La méthode courante a été appelée par une première méthode qui est la méthode rattachée au Frame 1 dans la Figure Fonctionnement de la machine virtuelle Java Cette partie spécifie les traitements effectués lors de l exécution d un programme Java. Elle est organisée autour du cycle de vie de la machine virtuelle Java. Elle présente les traitements effectués lors du lancement de la machine virtuelle, lors du chargement des classes et des interfaces manipulées, lors de la liaison et lors de l opération d initialisation. Elle conclut par une description de la terminaison de la machine virtuelle Démarrage de la machine virtuelle Une machine virtuelle Java commence son exécution lorsque la méthode main d une classe Java est appelée. Ceci provoque le chargement de la classe spécifiée, la liaison avec d autres types (classes ou interfaces Java) utilisés et l initialisation des types chargés. A présent, prenons, comme exemple de programme Java, la classe Essai spécifiée dans la Figure 3-5 et suivons, pas à pas, les étapes par lesquelles passe la machine virtuelle Java pour exécuter ce programme. class Essai { Valeur val ; public Essai (Valeur val_init) { this.val = val_init ; } public void plus ( ) { this.val.plus ; } public static void main (String args[ ]) { Essai e ; Valeur v ; class Valeur { static int no_init = 5 ; private int no ; public Valeur ( ) { this.no = this.no_init ; } public void plus ( ) { this.no ++ ; } } } } v = new Valeur ( ) ; e = new Essai (v) ; e.plus () ; Figure 3-5 : Exemple programme Java Chargement Au moment d exécuter la méthode main de la classe Essai, la machine virtuelle Java découvre qu elle ne possède aucune représentation de la classe Essai : la classe Essai n a pas été chargée. La machine virtuelle utilise alors un ClassLoader (chargeur de classe) pour charger la classe de nom Essai. 24

33 3 Machine Virtuelle Java Liaison Une fois la classe Essai chargée, les types (classes et interfaces Java) utilisés par cette classe doivent être liés. L opération de liaison passe par les trois étapes suivantes : la vérification, la préparation et la résolution. La première étape de l opération de liaison consiste à vérifier que la représentation de la classe Essai et de sa table des symboles (constant pool) est bien formée, et que le code de la classe Essai répond bien à la sémantique de la machine virtuelle Java. Cette opération est appelée vérification. La seconde étape de l opération de liaison consiste à allouer certaines structures de données nécessaires à la machine virtuelle, telles que les tables de méthodes. Cette étape est appelée préparation. Une dernière étape de l opération de liaison est l étape de résolution. Cette étape consiste à traduire les références symboliques, utilisées dans la classe Essai, en références directes. Les références symboliques sont des références vers d autres classes ou d autres interfaces, telles que la classe Valeur dans l exemple de la Figure 3-5. La liaison peut être faite de façon statique, au début du lancement d un programme, ou de façon dynamique, à l exécution, lors de l accès à une référence symbolique Initialisation Une fois que les opérations de chargement et de liaison de la classe Essai sont réalisées, il faut procéder à l initialisation de cette classe. Cette opération consiste à initialiser les attributs qui sont partagés par toutes les instances de la classe Essai ; ces attributs sont appelés variables de classe. Mais l initialisation de la classe Essai exige l initialisation, de façon récursive, de ses super-classes, et donc, de la classe-mère Object dans l exemple de la Figure 3-5. Une fois toutes ces opérations effectuées, la méthode main de la classe Essai peut être exécutée. L interprète Java lit, une à une, chacune des instructions de byte code de la méthode main, la traduit et l exécute Terminaison de la machine virtuelle La machine virtuelle Java se termine lorsqu une des deux conditions suivantes est vérifiée : Tous les threads non démons (daemon, section 3.4) se sont terminés. Un thread a pu exécuter la méthode exit de classe Java Runtime ou de la classe Java System. 3.4 Threads Java La machine virtuelle Java peut supporter plusieurs threads à la fois. Ces threads exécutent séparément du code Java, manipulant des valeurs et des objets Java résidant dans une même mémoire partagée. Un thread peut être démon (daemon) s il a été initialisé comme tel avant son lancement ou si le thread qui l a créé est lui-même démon. Initialement, la machine virtuelle est lancée avec un unique thread non démon qui appelle la méthode main d une classe. D autres threads peuvent être créés durant la vie de la machine virtuelle ; celle-ci se termine lorsque tous les threads non démons sont morts. 25

34 3 Machine Virtuelle Java Si aucun objet Thread n est créé durant la vie de la machine virtuelle Java, il n existera qu un seul thread, celui lancée lors du démarrage de la machine virtuelle ; et c est ce thread qui interprétera le code exécuté. Lorsqu un thread est créé, une pile Java lui est allouée. Ce thread peut alors exécuter la boucle d interprétation des instructions de byte code qui lui sont associées Structure du contexte d exécution d un thread Java Le contexte d exécution d un thread Java est composée de plusieurs structures de données que nous présentons ci-dessous. Il y a, tout d abord, une pile Java associée au thread et qui contient un ensemble de frames. Un frame est associée à une méthode appelée par le thread et non encore terminée. Le frame contient, entre autres informations, un compteur de programme de la méthode associée (registre pc), les variables locales de la méthode associée et les résultats intermédiaires stockés dans la pile des opérandes. Il y a, ensuite, la zone des méthodes associées au thread. Cette zone de méthodes contient le code des méthodes des classes utilisées par le thread et les tables de symboles, appelées constant pool, associées à ces classes. Il y a, enfin, la zone mémoire du tas qui contient les objets Java manipulés par le thread. Le contexte d exécution d un thread Java est donc composé d une pile Java représentant l image de l exécution du thread, d un tas contenant les objets (données) manipulés par le thread et d une zone de méthodes représentant le code exécuté par le thread. Une illustration de ce contexte est proposée dans la Figure 3-6. Les mécanismes proposés pour la migration de thread Java doivent donc manipuler ces trois structures de données. Zone de méthodes Pile Java Tas d objets Java Légende Réf. vers classe ou objet Java Classe Java Objet Java Figure 3-6 : Contexte d'exécution d'un thread Java 26

35 4 Réalisation de mécanismes de migration de threads Java Chapitre 4 4 Réalisation de mécanismes de migration de threads Java Ce chapitre décrit, tout d abord, les mécanismes nécessaires à la migration de threads Java. Il définit ensuite les principes de l adaptation de la migration aux besoins de l application l utilisant. Puis il explique le traitement permettant de fournir une migration de threads entre machines hétérogènes. Finalement, un plan de travail est proposé pour décrire les différentes étapes de réalisation. 4.1 Mécanismes de migration Pour permettre la migration de threads Java, des mécanismes supplémentaires doivent être intégrés à la machine virtuelle Java. Ce besoin d extension vient du fait que la migration de threads exige certaines informations et certains traitements que la machine virtuelle Java, telle qu elle est conçue actuellement, ne procure pas. Les extensions à apporter à la machine virtuelle Java visent principalement l ajout de mécanismes permettant tout d abord d interrompre un thread Java, en cours d exécution, et d extraire son contexte d exécution, de transférer ensuite ce contexte d exécution vers une machine distante et de créer enfin un nouveau thread Java en y intégrant le contexte reçu pour qu il reprenne l exécution au point même où elle a été interrompue. Voici une présentation de chacun de ces mécanismes Mécanisme d extraction du contexte d exécution d un thread Ce mécanisme a pour rôle d interrompre l exécution d un thread Java et d extraire l image de son exécution. L image d exécution d un thread, ou son contexte d exécution, est une structure de données contenant les informations nécessaires à la restitution de ce contexte ; ces informations étant relatives au code exécuté par ce thread, aux données qu il manipule et à l état d avancement de son exécution. Nous présentons, dans ce qui suit, les traitements nécessaires à l opération d extraction du contexte d exécution d un thread préalablement interrompu. Ceci est fait en décrivant les traitements effectués autour de chacune des trois structures de données constituant le contexte d exécution d un thread Java et qui sont la pile Java, le tas d objets et la zone de méthodes Traitements utilisant la pile Java La pile Java est une des structures de données constituant le contexte d exécution d un thread. Le mécanisme d extraction de contexte doit effectuer une copie des frames contenus 27

36 4 Réalisation de mécanismes de migration de threads Java dans la pile Java, pour pouvoir ainsi reconstruire l état d exécution du thread et reprendre l exécution au point même où elle a été interrompue. La pile Java est le composant principal du contexte d exécution d un thread. Elle fournit des informations sur le contenu des autres composants tels que le tas d objets ou la zone de méthodes. En effet, c est dans la pile Java que l on trouve les références vers les objets et les classes Java manipulés par le thread. De ce fait, lors du traitement de la pile Java, une liste des références vers les objets utilisés et une liste des noms et des références des classes Java contenues dans la pile Java doit être construite. De plus, certaines informations complémentaires et nécessaires à la restitution du contexte doivent être calculées à partir de la pile Java. Ces informations concernent la transformation de certaines valeurs absolues en valeurs relatives. La valeur du registre pc d un frame, par exemple, est une valeur absolue, elle représente l adresse de la prochaine instruction à exécuter. Après migration, le code exécutée n est plus à la même adresse. Il faut calculer la valeur relative correspondante, pour pouvoir ainsi restituer la bonnes valeur absolue, lors de la restitution du contexte. Liste des objets et des classes Java manipulés Il faut construire une liste des références d objets contenues dans la pile Java et une liste des noms et des références des classes Java utilisées par la pile Java. Les noms et les références des classes utilisées sont donnés par des informations contenues dans les frames de la pile Java. Les références vers les objets manipulés peuvent être récupérées à partir des tables de variables et des piles d opérandes contenues dans les frames de la pile Java. Mais une table de variables ou une pile d opérandes peut contenir des valeurs de différents types : entier, réel ou référence Java par exemple. Et aucune information donnant le type de ces valeurs n est connue de façon statique. La seule façon d obtenir cette information est d effectuer un traitement supplémentaire lors de l interprétation des instructions de byte code. Ce traitement est abordé plus en détail en section 4.3. Transformation des valeurs absolues en valeurs relatives Quant à la transformation de certaines valeurs absolues en valeurs relatives, elle est faite en trouvant, pour chacune de ces valeurs absolues, un point de référence qui permet de calculer une valeur de décalage et donc, une valeur relative. Dans la structure d un frame, il existe un champ particulier qui est une adresse (un pointeur C) vers le frame précédent. Pour traduire une telle valeur absolue, il faut prendre un point de référence, l adresse du premier frame empilé dans la pile Java par exemple. Il faut ensuite calculer le décalage entre l adresse du frame précédent et l adresse du premier frame pour obtenir une valeur relative. La pile Java contient plusieurs valeurs absolues qui sont des pointeurs C, que ces pointeurs pointent vers des éléments de la pile Java elle-même, comme c est le cas pour le pointeur de frame précédent présenté plus haut, ou qu ils pointent vers d autres structures, comme pour le registre pc qui pointe vers la structure de zone de méthodes. Il faut transformer tous ces pointeurs, toutes ces valeurs absolues en valeurs relatives, pour que les nouvelles valeurs absolues puissent être restituées correctement lors de la restitution du contexte d exécution dans un nouveau thread. Cette partie a présenté une des étapes nécessaires à l extraction du contexte d exécution d un thread. Elle consiste à effectuer certains traitements autour de la pile Java du thread en recopiant ses frames, en transformant certaines de ses valeurs absolues en valeurs relatives et en récupérant les références vers les objets manipulés et les noms et les références des classes Java utilisées par le thread. Ce dernier traitement, qui consiste à récupérer les références des objets et les noms et les références des classes, permet d effectuer des traitements autour des deux structures de tas d objets et de zone de méthodes. 28

37 4 Réalisation de mécanismes de migration de threads Java Traitements utilisant le tas d objets Les traitements effectués autour de la structure de pile Java ont permis de construire une liste de références vers les objets Java manipulés par le thread. C est grâce à cette liste que l identification des objets Java, se trouvant dans le tas d objets et utilisés par le thread, peut être faite. Une des étapes d extraction du contexte d exécution d un thread est la récupération des objets qu il manipule. Nous nous restreignons ici à un cas simplificateur où tous les objets manipulés par un thread sont recopiés et intégrés au contexte d exécution extrait. Nous verrons plus tard (section 4.2) qu une solution plus adaptable permet de spécifier, pour certains types d objets, des traitements supplémentaires effectués lors de l extraction du contexte d exécution d un thread. Un objet Java peut référencer d autres objets Java formant ainsi une structure de graphe. La recopie des objets manipulés par un thread se fait donc en parcourant les graphes d objets et en les stockant dans une structure qui permet leur acheminement vers une machine distante et la reconstitution des graphes de départ. L opération de sérialisation de Java [JDK1.1.3] permet d effectuer un tel traitement Traitements utilisant la zone de méthodes Les traitements effectués autour de la structure de pile Java produisent une liste des noms et des références de classes Java manipulées par le thread. C est grâce à cette liste que l identification des classes Java, se trouvant dans la zone de méthodes et utilisées par le thread, peut être faite. Donc, c est grâce à cette liste que le code des méthodes appelées par ce thread, et dont l exécution n est pas finie, peut être identifié. Et un des rôles du mécanisme d extraction du contexte d exécution d un thread est de fournir les informations nécessaires à la restitution ultérieure du code exécuté par le thread. Lors de l extraction du contexte d exécution d un thread Java, aucun traitement n est fait autour de la zone de méthodes. La liste des noms et des références des classes Java, construite auparavant, suffit. En effet, grâce à cette liste de classes, un chargement de ces classes, à partir d une machine distante, peut être fait en utilisant le mécanisme de ClassLoader (chargeur de classe) fourni par Java [JDK1.1.3]. Pour des raisons d adaptabilité, ce chargement de classes peut être fait par l application utilisant nos mécanismes de migration. Mais il est important de noter que ces classes doivent absolument être chargées avant l étape d intégration du contexte (section 4.1.3) puisqu elles sont référencées dans le contexte d exécution du thread et seront donc utilisées lorsque le nouveau thread sera lancé Mécanisme de transfert d un contexte d exécution Ce mécanisme a pour objectif de transférer le contexte d exécution d un thread d une machine virtuelle Java source vers une machine virtuelle Java destination. Les informations acheminées lors de ce transfert sont les structures de données construites lors de l extraction du contexte d exécution d un thread. Ces structures de données sont composées d une copie de la pile Java et d une liste de valeurs absolues transformées en valeurs relatives, d une structure de données stockant une copie des objets manipulés par le thread, d une liste des références de ces objets et d une liste des noms et des références des classes manipulées par le thread. Nous présentons ce mécanisme en décrivant les traitements effectués autour de chacune des trois structures de données constituant le contexte d exécution d un thread Java et qui sont la pile Java, le tas d objets et la zone de méthodes. 29

38 4 Réalisation de mécanismes de migration de threads Java Traitements utilisant la pile Java Le mécanisme d extraction du contexte d exécution d un thread permet, entre autres opérations, de construire une copie de la pile Java et une liste de valeurs relatives obtenues à partir de valeurs absolues. Le mécanisme de transfert du contexte d exécution doit donc transférer ces deux structures de données de la machine source vers la machine destination. Ces deux structures permettront d initialiser le contexte d exécution d un nouveau thread sur la machine destination, lors de l utilisation du mécanisme d intégration de contexte d exécution (section 4.1.3) Traitements utilisant le tas d objets Le mécanisme d extraction du contexte d exécution d un thread construit, d une part, une liste des références vers les objets Java manipulés par le thread et, d autre part, une structure de données stockant les graphes d objets. Le mécanisme de transfert du contexte d exécution doit envoyer la liste des références d objets et la structure de graphes d objets d une machine virtuelle Java source vers une machine virtuelle Java destination. Une fois sur la machine destination, il faut reconstruire, à partir de la structure de graphes d objets reçue, de nouveaux graphes d objets équivalents aux graphes d objets initiaux. Ceci est fait grâce à l opération de désérialisation de Java [JDK1.1.3]. De plus, il faut effectuer une correspondance entre les références initiales des objets sur la machine source et les références nouvellement construites sur la machine destination. Cette correspondance servira à mettre à jour les références vers les objets Java dans la pile Java du thread, lors de l utilisation du mécanisme d intégration de contexte d exécution Traitements utilisant la zone de méthodes Le mécanisme d extraction du contexte d exécution d un thread construit, entre autres informations, une liste des noms et des références des classes utilisées par le thread. Lors de l opération de transfert du contexte d exécution d une machine source vers une machine destination, cette liste doit être envoyée vers la nouvelle destination. Grâce aux noms de classes, le code de ces classes peut être chargé en utilisant un ClassLoader Java (chargeur de classe). Java permet de mettre en œuvre le chargeur de classes Java (ClassLoader) le plus approprié et le plus adapté aux besoins de l application l utilisant. Une application peut, par exemple, charger les classes Java à partir du système de gestion de fichiers local ou à partir d une source réseau (chargement à distance). Dans un but d adaptabilité, le chargement des classes Java n est pas fait par le mécanisme de transfert du contexte d exécution. Nous laissons cette opération à la charge de l application utilisant ce mécanisme sur la machine destination. Cette application a ainsi la possibilité d adapter et de spécialiser sa politique de chargement des classes lors d un transfert de contexte. Le seul traitement que doit effectuer ici le mécanisme de transfert de contexte est de fournir, à l application l utilisant, la liste des noms de classes à charger Mécanisme d intégration d un contexte d exécution à un nouveau thread Le mécanisme d intégration d un contexte d exécution à un nouveau thread consiste à créer un nouveau thread, à l initialiser avec une certaine image d exécution et à lancer son exécution pour que celle-ci reprenne au point même où elle a été interrompue. L image 30

39 4 Réalisation de mécanismes de migration de threads Java d exécution initiale affectée au thread est codée dans un ensemble de structures de données appelé contexte d exécution. La première étape de ce mécanisme est de créer un nouveau thread Java et de lui allouer une pile Java vide. Il faut ensuite intégrer un contexte à ce thread avant de pouvoir relancer son exécution. L intégration du contexte d exécution au nouveau thread effectue différents traitements relatifs aux structures de données de pile Java, de tas d objets et de zone de méthodes. Nous présentons, dans ce qui suit, chacun de ces traitements Traitements utilisant la pile Java Le mécanisme proposé ici doit intégrer un contexte d exécution à un nouveau thread créé avec une pile Java vide. Ce contexte est constitué, entre autres informations, d une pile Java et d une liste de valeurs relatives obtenues à partir de valeurs absolues. Les traitements à effectuer sont la recopie de la pile Java et la reconstitution de valeurs absolues à partir de valeurs relatives. La pile Java du contexte doit donc être recopiée dans la pile Java vide du thread créé. Il faut ensuite reconstituer les valeurs absolues à partir de la liste des valeurs relatives contenues dans le contexte. Ces valeurs absolues concernent certaines valeurs contenues dans la pile Java telles que la valeur du registre pc d un frame de la pile ou la valeur du pointeur frame précédent dans un frame de la pile. Pour ce qui est des traitements relatifs à la mise à jour des références d objets et de classes contenues dans la pile Java du thread, ceux-ci seront abordés dans les sections suivantes Traitements utilisant le tas d objets Le mécanisme de transfert de contexte d exécution a permis de reconstruire le tas d objets du thread. Autrement dit, de nouveaux objets Java, équivalents aux objets initiaux, ont été construits. Le mécanisme d intégration du contexte d exécution doit rattacher ces nouveaux objets Java au thread nouvellement créé. En effet, certaines informations contenues dans la pile Java du thread représentent des références vers des objets Java initiaux (utilisés par le thread interrompu grâce au mécanisme d extraction de contexte d exécution). Ces anciennes références d objets doivent être remplacées par des références vers les nouveaux objets créés. Cette mise à jour est effectuée grâce à la correspondance établie, entre les anciennes références d objets et les nouvelles références d objets, lors du transfert du contexte d exécution Traitements autour de la zone de méthodes Lors de l étape de transfert du contexte d exécution, une liste de noms et de références de classes a été envoyée à la nouvelle localisation du thread. Le chargement de ces classes a été réalisé par l application faisant appel à ces mécanismes de migration. Après cette étape de chargement, l application doit fournir au mécanisme d intégration de contexte d exécution la liste des références vers ces classes chargées. Cette liste de nouvelles références permettra de mettre à jour les références vers les classes contenues dans la pile Java Lancement de l exécution du nouveau thread Le thread ainsi créé est donc initialisé avec un certain contexte d exécution lui permettant de reprendre son exécution au point même où elle a été interrompue. L ultime traitement à effectuer est de lancer l exécution de ce thread pour qu il interprète les instructions de byte code constituant la suite du code qui reste à exécuter. 31

40 4 Réalisation de mécanismes de migration de threads Java 4.2 Mécanisme d adaptation de la migration Le mécanisme d adaptation proposé ici n est pas un mécanisme que nous fournissons mais plutôt un principe de mécanisme que doit fournir l application utilisant les mécanismes de migration présentés précédemment. La mise en œuvre du mécanisme d adaptation de la migration est à la charge de l application utilisant la migration de threads Java. Le principe du mécanisme d adaptation que nous proposons permet de spécifier, pour certains types d objets utilisés par un thread, des traitements supplémentaires effectués lors de la migration de ce thread. Pour illustrer le principe d un tel mécanisme, prenons un exemple d application Java. Considérons une application de type Clients-Serveur, composée de plusieurs sites Clients et d un site Serveur connu par tous les sites clients. Un site client peut supporter plusieurs threads Java. Un thread, sur un site client, communique avec le serveur via un objet Java de type Socket. La Figure 4-2 illustre cet exemple. Que se passe-t-il lorsqu un tel thread, sur un site client source, est transféré vers un site client destination? Comment se passent, lors de la migration, les traitements qui sont faits autour des objets manipulés par ce thread? Et, plus précisément, comment est traité, lors de la migration, l objet Socket manipulé par le thread client? Une adaptation possible du mécanisme de migration est de décider que l objet Socket, utilisé par un thread client pour communiquer avec le serveur, doit être fermé avant le transfert du contexte d exécution de ce thread vers le site destination. Et lors de la restitution du contexte dans un nouveau thread, sur le site destination, un nouvel objet Socket est créé pour ce thread et la connexion avec le serveur est rétablie. Nous avons vu, précédemment, qu une migration de thread d une machine source vers une machine destination passe par une étape d extraction du contexte d exécution du thread, suivie d une étape de transfert de ce contexte de la machine source vers la machine destination et, enfin, d une étape d intégration de ce contexte à un nouveau thread créé sur la machine destination. Nous présentons, dans ce qui suit et pour chacune des trois étapes de la migration, le principe d un mécanisme d adaptation à mettre en œuvre pour cet exemple d application. Site serveur Site client source Site client destination Thread Socket Thread Socket Avant migration Après migration Figure 4-2 : Exemple d application 32

41 4 Réalisation de mécanismes de migration de threads Java Adaptation lors de l extraction du contexte d exécution Lors de l extraction du contexte d exécution du thread sur le site client source, une structure de données stockant les objets manipulés par ce thread est construite grâce à l opération de sérialisation de Java [JDK1.1.3]. Une telle opération permet de transformer un graphe d objets en une structure de données qui peut être transférée vers un autre site. Pour qu un objet Java puisse être sérialisé, il faut que la classe de cet objet implémente l interface Java Serializable. Il faut, de plus, que cette classe fournisse une méthode de nom writeobjetc qui spécifie les traitements à effectuer lors de la sérialisation des objets de cette classe. La classe de l objet Socket, manipulé par un thread client, doit donc implémenter l interface Java Serializable et fournir une méthode writeobject qui ferme l objet Socket et ajoute, à la structure de données stockant les objets, une information désignant la présence d un objet Socket. L écriture d une telle méthode writeobject permet donc d adapter le traitement des objets de type Socket, lors de l extraction du contexte d exécution d un thread client Adaptation lors du transfert du contexte d exécution Le mécanisme de transfert du contexte d exécution d un thread, d un site source vers un site destination, permet d envoyer, au site destination, une structure de données stockant les graphes d objets manipulés par ce thread. Un des traitements effectués à cette étape est la construction, sur le site destination, de nouveaux graphes d objets, équivalents aux graphes initiaux. Ceci est fait grâce à l opération de désérialisation de Java. Pour pouvoir effectuer une opération de désérialisation sur un objet, il faut que la classe de cet objet implémente l interface Java Serializable. Il faut, de plus, que cette classe fournisse une méthode de nom readobjetc qui spécifie les traitements à effectuer lors de la désérialisation des objets de cette classe. La classe de l objet Socket, manipulé par un thread client, doit donc implémenter l interface Java Serializable et fournir une méthode readobject qui initialise le nouvel objet Socket (avec l adresse IP et le numéro de port) et ouvre une connexion entre ce thread client et le site serveur. L écriture d une telle méthode readobject permet donc d adapter le traitement des objets de type Socket, lors du transfert du contexte d exécution d un thread client Adaptation lors de l intégration du contexte d exécution Une fois que le contexte d exécution est reçu sur le site client destination, un nouveau thread client est créé et de nouveaux objets Java sont construits. L étape d intégration doit relier les nouveaux objets au nouveau thread. Grâce à la correspondance établie entre les références des anciens objets Java (sur le site source) et les références des nouveaux objets Java (sur le site destination), la mise à jour des liaisons entre le thread et les objets qu il manipule peut être faite. Pour l exemple d application considéré, aucun traitement pour l adaptation n est ajouté à cette étape de la migration de thread. 4.3 Traitement de l hétérogénéité Lors de la réalisation du mécanisme d extraction du contexte d exécution d un thread, nous avons rencontré un problème particulier lié à l hétérogénéité des mécanismes de migration que nous fournissons. Ce problème a été rencontré lors du traitement de la pile Java d un thread. 33

42 4 Réalisation de mécanismes de migration de threads Java Principe du traitement La pile Java d un thread contient des tables de variables et des piles d opérandes associées aux frames de cette pile Java. Ces deux structures de données, qui sont la table de variables et la pile d opérandes, peuvent contenir des valeurs de différents types telles que des valeurs entières, des valeurs réelles ou des valeurs de type référence vers un objet Java. Chacune de ces structures de données est représentée, dans la machine virtuelle Java, dans un format dépendant de la machine (structures C). Pour des raisons d hétérogénéité, le mécanisme d extraction du contexte d exécution d un thread doit recopier ces structures de données d un format dépendant de la machine (structure C) vers un format indépendant de la machine (structure Java). Pour effectuer cette traduction de format, il faut recopier, une à une, chacune des valeurs contenues dans une table de variables ou dans une pile d opérandes, selon le type de cette valeur. Or, le type des valeurs contenues dans ces deux structures de données ne peut être connu lors de l extraction du contexte d un thread ; ces deux structures ne contiennent pas d information sur les types de leurs valeurs. Une telle information sur le type ne peut être obtenue qu au cours de l interprétation des instructions de byte code. En effet, une instruction de byte code est typée : elle s applique à un type défini de valeur (voir la liste des instructions de byte code en Annexe 1). Pour connaître les types des valeurs, il faut effectuer des traitements supplémentaires lors de l interprétation du byte code. Il faut construire une structure de données qui donne, pour chaque valeur contenue dans les tables de variables ou les piles d opérandes de la pile Java d un thread, le type de cette valeur. Ainsi, grâce à cette structure de données contenant les types des valeurs, la recopie de la pile Java, d un format dépendant de la machine vers un format indépendant de la machine, peut être faite Traitement restrictif Pour éviter que les traitements pour le type des valeurs, rajoutés au processus d interprétation du byte code, ne soient exécutés par tout thread Java, une solution restrictive est proposée. Cette solution consiste à ne pas fournir les mécanismes de migration dans la classe Thread de Java mais dans une nouvelle classe que nous appelons MobileThread. Nous définissons cette classe comme étant une sous-classe de la classe Thread, elle caractérise les threads Java qui sont mobiles, qui peuvent se déplacer d une machine virtuelle Java vers une autre machine virtuelle Java. Ainsi, les traitements rajoutés, au processus d interprétation, pour l hétérogénéité ne sont effectués que pour les threads qui sont mobiles et qui ont besoin de ces traitements. Les extensions de la classe Thread, présentées précédemment, doivent donc être faites dans la classe proposée MobileThread. 4.4 Etapes de réalisation Voici un plan de travail donnant les étapes successives, nécessaires à la réalisation des mécanismes présentés précédemment : Traitement de la pile Java dans un système homogène : lors de l extraction du contexte d exécution et lors de l intégration du contexte d exécution. 34

43 4 Réalisation de mécanismes de migration de threads Java Ces deux étapes ont été réalisées durant ce stage de DEA. Ceci a été fait en rajoutant à la classe Thread de Java deux méthodes : stopbeforemigration et strataftermigration (Les extensions présentées ici sont faites, dans un premier temps, dans la classe Thread de Java. Mais ces extensions seront intégrées, ultérieurement, à une nouvelle classe de nom ThreadMobile). La méthode stopbeforemigration permet d interrompre un thread et de récupérer son contexte courant. La méthode strataftermigration, qui a comme paramètre un contexte d exécution, permet de créer un nouveau thread, d y intégrer le contexte passé en paramètre et de lancer l exécution de ce thread. Pour l instant, le contexte d exécution considéré dans ces méthodes ne prend pas en compte le tas d objets et la zone des méthodes ; il ne contient que la pile Java d un thread. Ces deux étapes ont permis d expérimenter, dans un premier temps, une partie des mécanismes d extraction et d intégration du contexte d exécution d un thread. En effet, grâce à cette réalisation, on peut arrêter un thread, en cours d exécution sur une machine virtuelle Java, et créer, sur cette même machine virtuelle, un nouveau thread qui continue l exécution du premier thread. Le nouveau thread utilise le même tas d objets et la même zone de méthodes que le premier thread. Quant aux étapes suivantes, elles sont encore en cours de réalisation. Traitement de l hétérogénéité. Cette étape consiste à rajouter, au processus d interprétation du byte code, les traitement nécessaires à la prise en compte de l hétérogénéité. Traitement du tas d objets : lors de l extraction du contexte d exécution et lors de l intégration du contexte d exécution Traitement de la zone des méthodes : lors de l extraction du contexte d exécution et lors de l intégration du contexte d exécution. Ces trois derniers traitements permettent d arrêter un thread, en cours d exécution sur une machine virtuelle Java, et de créer, sur cette même machine virtuelle, un nouveau thread qui continue l exécution du premier thread. Mais le nouveau thread n utilise plus le même tas d objets et la même zone de méthodes que le premier thread, il a son propre tas d objets et sa propre zone de méthodes. Mécanisme de transfert du contexte d exécution. Traitement de la pile Java. Traitement du tas d objets. Traitement de la zone des méthodes. Une fois ce mécanisme de transfert réalisé, nous pourrons effectivement déplacer un thread Java d une machine vers une autre, dans un système hetérogène. Mécanismes d adaptation. Premier exemple de migration adaptable : le thread utilise un objet de type Socket. Dans ce cas, la migration peut être adaptée en fermant l objet Socket avant migration et en créant un nouvel objet Socket et en rétablissant sa connexion après migration. Deuxième exemple de migration adaptable : le thread manipule un fichier local à la machine sur laquelle il s exécute. Une adaptation possible de la migration de ce thread est d établir un lien de poursuite entre le nouveau site du thread et le site sur lequel se trouve le fichier. Ainsi, après la migration du thread, celui-ci accédera au fichier à distance. 35

44

45 5 Evaluation des mécanismes proposés Chapitre 5 5 Evaluation des mécanismes proposés Nous présentons, dans ce chapitre, les expérimentations nécessaires à la validation des mécanismes de migration que nous proposons. Ces expérimentations doivent, tout d abord, valider les hypothèses de base de nos mécanismes, et qui sont la migration forte, l hétérogénéité et l adaptabilité. Elles doivent, ensuite, valider ces mécanismes en prenant des exemples d applications les utilisant, tels que les agents mobiles, le clone de thread à distance et la sauvegarde de l état d un thread pour une reprise après panne. 5.1 Hypothèses de base Les objectifs de ce stage de DEA sont de fournir des mécanismes de migration de threads. Ces mécanismes sont dotés des caractéristiques suivantes : La migration forte qui permet de déplacer un thread, d une machine à une autre, et de continuer l exécution, sur la nouvelle machine, au point même où elle a été interrompue. L hétérogénéité qui permet de déplacer un thread entre machines hétérogènes. La portabilité qui se concrétise par l intégration des mécanismes proposés dans un système déjà existant et répandu, qui est la machine virtuelle Java. L adaptabilité qui permet de spécialiser la migration de threads pour qu elle réponde, au mieux, aux besoins de l application l utilisant. 5.2 Validation des hypothèses de base Les mécanismes que nous proposons doivent faire l objet d expérimentations pour valider les critères de migration forte, d hétérogénéité et d adaptabilité Validation de la migration forte Cette expérimentation doit vérifier, d une part, que la migration d un thread effectue bien le déplacement de ce thread d une machine à une autre et, d autre part, que l exécution du thread, après migration, reprend au point même où elle a été interrompue. L état courant de notre réalisation nous permet de vérifier cette dernière condition qui est la reprise de l exécution au point où elle a été interrompue. 37

46 5 Evaluation des mécanismes proposés En effet, notre extension de la machine virtuelle Java, et plus particulièrement de la classe Thread, fournit les deux méthodes stopbeforemigration et startaftermigration. Ces deux méthodes permettent, respectivement, d interrompre un thread et d extraire son contexte courant puis de créer un nouveau thread, d y intégrer le contexte d exécution passé en paramètre de la méthode et de lancer son exécution. Grâce à cette première réalisation, nous pouvons arrêter un thread qui s exécute sur une machine virtuelle Java, récupérer son contexte d exécution courant puis créer un nouveau thread, sur cette même machine virtuelle, y intégrer le contexte précédemment extrait et lancer son exécution pour qu elle reprenne au point où elle a été interrompue. Voici une illustration de cette première expérimentation. public class ArretThread extends Thread { public void run() { System.out.print("DEBUT run ArretThread : ") ; System.out.println(this) ; this.stopbeforemigration() ; System.out.print("FIN run ArretThread : ") ; System.out.println(this) ; } public static void main(string args[ ] ) { ArretThread at ; RepriseThread rt ; System.out.print("DEBUT main ArretThread : "); System.out.println(currentThread()) ; // Creation et lancement d un thread // qu on arretera at = new ArretThread() ; at.start() ; // Le thread courant donne la main au thread // precedemment cree pour qu il soit arrete currentthread().yield() ; // Creation et lancement d un thread qui reprend // l execution du thread precedemment arrete rt = new RepriseThread(at) ; rt.start() ; class RepriseThread extends Thread { ArretThread arrete ; public RepriseThread(ArretThread a) { this.arrete = a ; } public void run() { ArretThread nouv = null ; System.out.print("DEBUT run RepriseThread : ") ; System.out.println(this) ; try { nouv = (ArretThread) startaftermigration(this.arrete, true) ; } catch (Exception e) { System.out.println("Erreur lors de la reprise") ; } } System.out.print("RepriseThread : nouv = ") ; System.out.println(nouv) ; System.out.print("FIN run RepriseThread : ") ; System.out.println(this) ; } } System.out.print("FIN main ArretThread : ") ; System.out.println(currentThread()) ; } Figure 5-1 : Illustration de la migration forte : Programme source Java Le programme Java, présenté dans la Figure 5-1, déclare une première classe appelée ArretThread qui implémente la classe Java Thread. La méthode principale de la classe ArretThread crée un premier thread at, lance son exécution puis crée un second thread rt et lance son exécution. Le thread at interrompt son exécution et le thread rt crée un nouveau thread, nouv, qui poursuit l exécution du thread at. L interruption et l extraction du contexte d exécution du thread at sont réalisées par la méthode stopbeforemigration. La création d un nouveau thread et l intégration du contexte à 38

47 5 Evaluation des mécanismes proposés ce thread sont réalisées par la méthode startaftermigration. Ces deux méthodes font partie des extensions que nous avons apportées à la classe Thread de Java. La Figure 5-2 présente la trace d exécution associée au programme de la Figure 5-1. Tandis que la Figure 5-3 décrit le schéma d exécution du programme de la Figure 5-1. DEBUT main ArretThread : Thread[main,5,main] DEBUT run ArretThread : Thread[Thread-4,5,main] FIN main ArretThread : Thread[main,5,main] DEBUT run RepriseThread : Thread[Thread-6,5,main] RepriseThread : nouv = Thread[Thread-7,5,main] FIN run RepriseThread : Thread[Thread-6,5,main] FIN run ArretThread : Thread[Thread-7,5,main] arrêt reprise Figure 5-2 : Illustration de la migration forte : Trace de l exécution main main Thread-4 at crée DEBUT de run temps arrêt crée Thread-6 rt crée Thread-7 nouv détruit FIN de run reprise Figure 5-3 : Illustration de la migration forte : Schéma d'exécution Légende Etats d un thread: actif prêt bloqué fini 39

48 5 Evaluation des mécanismes proposés L exécution du programme Java proposé est constituée de plusieurs threads. Il y a, tout d abord, le thread principal identifié par main. Le thread main crée un premier thread at, identifié par Thread-4. Le Thread-4 exécute le début de la méthode run de la classe ArretThread puis s interrompt pour que son contexte d exécution soit extrait. Il reste dans un état bloqué. Le thread main crée, ensuite, un second thread rt, identifié par Thread-6, et arrive à la fin de son exécution. Le Thread-6 crée un thread nouv, identifié par Thread-7, y intègre le contexte précédemment extrait puis détruit Thread-4 et se termine. Le Thread-7 commence alors son exécution en la reprenant au point où elle a été interrompue par Thread-4 : il poursuit l exécution de la méthode run de la classe ArretThread jusqu à sa fin. Cet exemple permet d illustrer le fonctionnement des mécanismes que nous avons réalisés. Ce n est certes qu une première étape de la réalisation mais elle reste la plus importante puisqu elle permet d identifier l image courante de l exécution d un thread. Le déplacement effectif d un thread d une machine à une autre est encore en cours de réalisation Validation de l hétérogénéité La machine virtuelle Java que nous avons étendue est dédiée à plusieurs plates-formes telles que les systèmes Solaris sur architecture Sparc, Solaris sur architecture de type x86, Microsoft Windows NT et Microsoft Windows 95. Valider l hétérogénéité de la migration que nous proposons revient à installer la machine virtuelle Java que nous avons étendue sur différentes plates-formes et à tester la migration de threads entre ces plates-formes. Le critère d hétérogénéité n a pas encore été validé puisqu il est en cours de réalisation Validation de l adaptabilité Pour valider les principes du mécanisme d adaptabilité de la migration, deux premières expérimentations sont proposées Manipulation d objets de type Socket Une première expérimentation consiste à adapter la migration de threads lorsque ceuxci manipulent des objets de type Socket. C est l exemple que nous avons présenté précédemment pour illustrer l adaptabilité de la migration (section 4.2). Cette adaptation consiste à fermer l objet Socket manipulé par un thread avant migration puis à créer un nouvel objet Socket, après migration, à l initialiser et à rétablir sa connexion Manipulation d objets de type Fichier Une deuxième expérimentation consiste à proposer une adaptation de la migration de threads lorsque ceux-ci manipulent des fichiers locaux aux machines sur lesquelles ils s exécutent. Le principe de cette adaptation est le suivant. Lorsqu un thread, qui doit être déplacé d une machine source vers une machine destination, manipule un objet Fichier local à la machine source, un lien de poursuite est établi entre la machine source et la machine destination. Ainsi, le thread, déplacé sur la machine destination, peut accéder à l objet Fichier à distance. 40

49 5 Evaluation des mécanismes proposés Cette adaptation de la migration est utilisable dans le cas d absence de pannes des sites et du réseau. Sinon, les liens de poursuite risquent de ne plus être valides. Ces deux propositions d adaptation de la migration seront expérimentées dès que la réalisation des mécanismes de migration est achevée. 5.3 Utilisation des mécanismes proposés Les mécanismes de migration que nous proposons sont des outils de base permettant de mettre en œuvre de nouveaux mécanismes. Nous proposons ici d expérimenter certains de ces mécanismes tels que la mobilité des agents, la création d un thread clone à distance ou la sauvegarde de l état d un thread pour une éventuelle reprise après panne Agents mobiles La plupart des plates-formes à agents proposent une faible mobilité des agents. Généralement, un agent déplacé ne continue pas son exécution au point où elle a été interrompue mais la reprend depuis le début. Une migration forte de ces agents pourrait être plus intéressante. De plus, l adaptabilité des mécanismes de migration que nous proposons permettrait de spécialiser les traitements effectués lors de la migration des agents et de les adapter en fonction des besoins de la plate-forme à agents concernée. Une plate-forme à agents mobiles est en cours d expérimentation au sein du projet Sirac. Cette plate-forme fournit une migration faible pour ses agents. Une de nos perspectives est de porter cette plate-forme à agents sur la machine virtuelle Java que nous avons étendue. Les agents pourront ainsi profiter d une migration forte et adaptable grâce aux mécanismes que nous proposons. Plate-forme à agents Site 1 Site 2 Site n agent mobile Machine Virtuelle Java étendue Archi.1 Archi.2 Archi.n Figure 5-4 : Porter une plate-forme à agents sur la JVM étendue 41

50 5 Evaluation des mécanismes proposés Clone de thread à distance Les mécanismes proposés sont certes dédiés à réaliser la migration de threads Java mais ils peuvent servir aussi à mettre en œuvre d autres mécanismes tels que la création de threads clones à distance. La création d un thread clone à distance peut être décomposée en plusieurs étapes successives : L interruption momentanée d un thread sur une machine source. L extraction du contexte d exécution de ce thread interrompu. Le transfert du contexte d exécution extrait de la machine source vers la machine destination. La création, sur la machine destination, d un nouveau thread dans lequel est intégré le contexte reçu. Le lancement de l exécution du nouveau thread sur la machine destination. Cette exécution reprend au point où elle a été interrompue. La reprise de l exécution du thread interrompu sur la machine source. Nous pouvons donc remarquer que ce mécanisme de création d un clone de thread à distance peut être réalisé grâce aux outils de base que nous avons proposés Sauvegarde de l état pour reprise après panne Un autre mécanisme pouvant utiliser nos outils de base est le mécanisme de reprise après panne. Un tel mécanisme sert à sauvegarder l état d un thread en cours d exécution. Grâce à cette sauvegarde, l exécution du thread peut être reprise, après une panne, au point où elle a été interrompue lors de la dernière sauvegarde. Le mécanisme de sauvegarde de l état peut être décomposé en plusieurs étapes successives : L interruption momentanée d un thread. L extraction du contexte d exécution du thread interrompu. La sauvegarde du contexte extrait dans une unité de stockage non volatile (disque dur). La reprise de l exécution du thread interrompu. La reprise après panne peut être décomposée en ces étapes successives : La récupération du contexte sauvegardé. La création d un nouveau thread dans lequel est intégré le contexte sauvegardé. Le lancement de l exécution du nouveau thread. Cette exécution reprend au point où elle a été interrompue lors de la dernière sauvegarde. Ce mécanisme de sauvegarde de l état pour reprise après panne peut donc utiliser nos deux outils d extraction du contexte d exécution d un thread et d intégration d un contexte d exécution à un nouveau thread. Deux autres outils sont nécessaires à ce mécanisme : l outil permettant de sauvegarder le contexte d exécution dans une unité de stockage et l outil permettant de récupérer le contexte d exécution à partir d une unité de stockage. 42

51 Conclusion Conclusion Nous avons proposé des mécanismes de migration de processus. Ces mécanismes permettent, d une part, de déplacer un processus, en cours d exécution, d une machine à une autre et, d autre part, d adapter la migration aux besoins de l application qui l utilise. Les objectifs de notre travail sont de fournir une migration forte qui permette à un processus déplacé de reprendre son exécution au point même où elle a été interrompue, de fournir une migration dans des systèmes hétérogènes et de permettre d adapter cette migration et de spécialiser les traitements effectués lors du déplacement d un processus. Le langage interprété Java permet de masquer l hétérogénéité des systèmes. Notre choix s est donc porté sur l extension de la machine virtuelle Java pour qu elle fournisse des mécanismes de migration adaptables. La méthode que nous avons adoptée pour aborder ce problème est d étudier, tout d abord, la structure de la machine virtuelle Java pour identifier le contexte d exécution d un processus Java et de définir, ensuite, les mécanismes intermédiaires nécessaires à la migration de processus. Ces mécanismes comprennent : le mécanisme qui permet d interrompre un processus en cours d exécution et d extraire son contexte, le mécanisme qui permet de transférer un contexte d exécution d une machine à une autre, le mécanisme qui permet de créer un nouveau processus, d y intégrer un contexte donné et de lancer le nouveau processus pour qu il continue l exécution, les mécanismes qui permettent de spécialiser le contenu du contexte transféré lors de la migration. Nos travaux ont fait l objet d une première réalisation. Cette réalisation permet d interrompre un processus s exécutant sur une machine virtuelle Java, d extraire son contexte d exécution et de détruire le processus interrompu, puis de créer un nouveau processus, sur cette même machine, d y intégrer le contexte extrait et de lancer ce processus. Le nouveau processus commence l exécution au point même où elle a été interrompue dans le premier processus. Cette première étape n est qu une étape préliminaire de la réalisation mais elle est, de loin, la plus importante puisqu elle permet d identifier l état d exécution d un processus, de l extraire puis de le restaurer. D autres travaux sont en cours pour réaliser le déplacement effectif d un processus d une machine virtuelle à une autre et pour expérimenter l adaptabilité des mécanismes fournis. Les mécanismes que nous proposons sont certes dédiés à la migration de processus mais ils ouvrent des voies vers d autres domaines d utilisation. De tels mécanismes peuvent, par exemple, servir à la création d un processus clone à distance, à la sauvegarde de l état 43

52 Conclusion d exécution d un processus pour une éventuelle reprise après panne ou, tout simplement, comme environnement de base à un système à agents mobiles. Notre première perspective, une fois que la réalisation des mécanismes présentés est achevée, est de porter une plate-forme à agents sur notre machine virtuelle Java étendue. Une telle plate-forme est en cours d expérimentation au sein de notre groupe. Nous prévoyons, à plus long terme, d utiliser les mécanismes que nous fournissons pour la sauvegarde de l état d exécution des processus (point de reprise) dans la perspective d une reprise après panne. Ce stage de DEA m a permis de réaliser un travail ouvrant la voie à de nombreuses perspectives applicatives. Il m a permis de m intéresser à des mécanismes de base tout en tenant compte des besoins des applications utilisant ces mécanismes. 44

53 Annexe Annexe Annexe 1 : Liste des instructions de byte code Java Voici une liste des instructions de byte code Java. Certaines de ces instructions commencent par une des lettres suivantes : b, s, i, l, f, d, c ou a pour indiquer respectivement des instructions appliquées sur des valeurs de type byte (octet), short, int, long, float, double, char ou référence Java. Instructions de chargement et de sauvegarde Les instructions de chargement et de sauvegarde transfèrent des valeurs entre les variables locales de la machine virtuelle Java et la pile des opérandes Java : Chargement d une variables locale dans la pile des opérandes : iload, iload_<n>, lload, lload_<n>, fload, fload_<n>, dload, dload_<n>, aload, aload_<n>. Sauvegarde d une valeur de la pile des opérandes vers les variables locales : istore, istore_<n>, lstore, lstore_<n>, fstore, fstore_<n>, dstore, dstore_<n>, astore, astore_<n>. Chargement d une constante dans la pile des opérandes : bipush, sipush, ldc, ldc_w, ldc2_w, aconst_null, iconst_m1, iconst_<i>, lconst_<l>, fconst_<f>, dconst_<d>. Instructions arithmétiques Les instructions arithmétiques calculent des fonctions binaires ou des fonctions unaires. En fonction du nombre d opérandes exigé, l instruction arithmétique dépile les opérandes de la pile des opérandes, calcule la fonction considérée et empile le résultat sur la pile d opérandes : Addition : iaad, ladd, fadd, dadd. Soustraction : isub, lsub, fsub, dsub. Multiplication : imul, lmul, fmul, dmul. Division : idiv, ldiv, fdiv, ddiv. Reste : irem, lrem, frem, drem. Négation : ineg, lneg, fneg, dneg. Décalage : ishl, ishr, iushr, lshl, lshr, lushr. OU bit à bit : ior, lor. 45

54 Annexe ET bit à bit : iand, land. OU exclusif bit à bit : ixor, lxor. Incrémentation d une variable locale : iinc. Instructions de conversion de type int vers long, float ou double, byte short ou char : i2l, i2f, i2d, i2b, i2s, i2c. long vers float, double ou int : l2f, l2d, f2i. float vers double, int ou long : f2d, f2i, f2l. double vers int, long ou float : d2i, d2l, d3f. Instructions de création et de manipulation d objets Une instance de classe et un tableau Java sont tous deux considérés comme des objets Java mais ils sont créés et manipulés avec des instructions différentes : Création d une nouvelle instance de classe : new. Création d un nouveau tableau : newarray, anewarray, multianewarray. Accès aux attributs d une classe (attributs static) et aux attributs d une instance (attributs non static) : getfield, putfield, getstatic, putstatic. Chargement d un élément de tableau dans la pile des opérandes : baload, caload, saload, iaload, laload, faload, baload, aaload. Sauvegarde d une valeur de la pile des opérandes dans un élément du tableau : bastore, castore, sastore, iastore, lastore, fastore, dastore, aastore. Longeur du tableau : arraylength. Vérifier les propriétés des instances de classes ou des tableaux : instanceof, checkcast. Instruction de manipulation directe des opérandes dans la pile pop, pop2, dup, dup2, dup_x1, dup2_x1, dup_x2, dup2_x2. Instruction de transfert de contrôle Branchement conditionnel : ifeq, iflt, ifle, ifne, ifgt, ifge, ifnull, ifnonnull, if_icmpeq, if_icmpne, if_icmplt, if_icmpgt, if_icmple, if_icmpge, if_acmpeq, if_acmpne, lcmp, fcmpl, fcmpg, dcmpl, dcmpg. Branchement conditionnel composé : tableswitch, lookupswitch. Branchement inconditionnel : goto, goto_w, jsr, jsr_w, ret. Instructions d appel de méthode et de retour de méthode Appel d une méthode d instance (non static) sur un objet : invokevirtual. Appel d une méthode implémentée par une interface : invokeinterface. Appel d une méthode d instance exigeant un traitement particulier telle qu une méthode d initialisation <init>, une méthode private ou une méthode de la super-classe : invokespecial. Appel d une méthode de classe (static) : invokestatic. 46

55 Annexe Instructions de propagation des exceptions Propagation d une exception : athrow. Instructions de synchronisation La synchronisation est gérée en utilisant le mécanisme de moniteurs : monitorenter, monitorexit. 47

56

57 Références bibliographiques Références bibliographiques [Arnold96] K. Arnold et J. Gosling. Le Langage Java. Paris : ITPF, [Artsy89] [Atkinson91] [Barak83] [Barnes91] [Baumann96] [Berners-Lee94] [Birrell84] [Campione96] [Chess87] [Douglis91] Y. Artsy et R. A. Finkel. Designing a Process Migration Facility : The Charlotte Experience. IEEE Computer, pages 47-56, Septembre C. Atkinson. Object-Oriented Reuse, Concurrency and Distribution. ACM Press, Addison-Wesley, A. Barak et A. Shiloh. A Distributed Load-Balancing Policy for a Multicomputer. Software Practice and Experience, pages , Septembre J. Barnes. Programmer en ADA. Addison-Wesley et InterEditions, M. Straber, J. Baumann et F. Hohl. Mole A Java Based Mobile Agent System. ECOOP 96 Workshop on Mobile Object Systems, T. Berners-Lee, R. Cailliau, A. Luotonen, H. F. Nielsen et A. Secret. The World Wide Web. Communications of the ACM, 37(8):76-82, Août A. D. Birrell et B. J. Nelson. Implementing Remote Procedure Calls. ACM Transactions on Computer Systems, pages 39-59, Février M. Campione et K. Walrath. The Java tutoroal : object-orinted programming for the Internet. Addison-Wesley, D. Chess, C. Harrison et A. Kershenbaum. Mobile Agent : Are They a good Idea? Rapport de recherche d IBM, (88465), pages 1-23, F. Douglis et J. Outerhout. Transparent Process Migration : Design Alternatives and the Sprite Implementation. Software Practice and Experience, 21(8): , Août

58 Références bibliographiques [Freedman91] D. Freedamn. Experience Building a Process Migration Subsystem for UNIX. USENIX Winter Conference, pages , Dallas, TX, Janvier [Galler62] B. A. Galler. The Language of computers. McGraw-Hill, [Garreta92] H. Garreta. C : Langage, Bibliothèque, Applications. InterEditions [General Magic95] The Telescript Language Reference, Version 1.0, Octobre [Gray96] [IBM96] [Jaulent83] [JDK1.1.3] [Johansen95] [Jul88] [Krakowiak85] R. S. Gray. Agent Tcl : A Flexible and Secure Mobile-Agent System. Proceedings of the 1996 Tcl/Tk Workshop, Juillet IBM Tokyo Research Labs. Aglets Workbench : Programming Mobile Agents in Java P. Jaulent. Le Microprocesseur et sa programmation. Editions Eyrolles, JDK Documentation Java Developer Kit. D. Johansen, R. van Renesse et F. Schneider. Operating System Support for Mobile Agents. Proceedings of the 5 th Workshop on Hot Topics in Operating System, E. Jul et al. Fine-Grained Mobility in the Emerald System. ACM Transactions on Computer Systems, 6(1), pages , Février S. Krakowiak. Principes des systèmes d exploitation des ordinateurs. Dunod, [Le Beux80] P. Le Beux. Introduction au Pascal [Milojicic93] [Milojicic97] [Milojicic98] D. Milojicic et al.. Task Migration on Top of the Mach MicroKernel. Proceeding of the third USENIX Mach Symposium, pages , Avril D. S. Milojicic, F. Douglis, Y. Paindaveine, R. Wheeler et S. Zhou. Process Migration. Mars D. Milojicic, W. LaForge et D. Chauchan. Mobile Objects and Agents (MOA), Design Implementation and Lessons Learned. USENIX COOTS 98, Avril

59 Références bibliographiques [Mukherjee94] [Nelson79] [Nuttall94] [O Connor93] A. Mukherjee. On the Dynamics and Significance of Low Frequency Components of Internet Load. Internetworking : Researche and Experience, 5(4), pages , Décembre P. A. Nelson. A Comparison of PASCAL Intermediate Languages. SIGPLAN Notices, 14(8), pages , M. Nuttall. A Brief Survey of Systems Providing Process or Object Migration Facilities. Operating System Review, 28(4) pages 64-79, Octobre. M. O Connor, B. Tangney, V. Cahill et N. Harris. Microkernel Support for Migration. Distributed Systems Engineering Journal, Décembre [Ousterhout94] J. K. Ousterhout. Tcl and Tk toolkit. Addison Wesley, [Perret97] [Powell83] [Ranganathan97] S. Perret. Agents mobiles pour l accès nomade à l information répartie dans les réseaux de grande envergure. Thèse de Doctorat, Université Joseph Fourier, M. L. Powell et B. P. Miller. Process Migration in DEMOS/MP. Proceedings of the 6 th ACM Symposium on Operating Systems Principles, pages , Novembre M. Ranganathan, A. Acharya, S. Dharma et J. Saltz. Network-aware Mobile Programs. Proceedings of the USENIX 1997 Annual Technical Conference, Anaheim, Californie, pages 1-13, Janvier [Rozier88] M. Rozier, V. Abrassimov, F. Armand, J ; boule, M. Gien, M. Guillemont, F. Herrmann, C. Kaiser, P. Léonard, S. Langlois et V. Neuhauser. Chorus Distributed Operating System. Computing Systems, USENIX, 1(4), pages , [Smith96] [Steengaard95] [Sun94] [Tanenbaum94] P. Smith et N. C. Hutchinson. Heterogeneous Process Migration : The Tui System. A Technical Report TR96-04, B. Steengaard et E. Jul. Object and Native Code Thread Mobility Among Heterogeneous Computers. Proceedings of the 15 th Symposium on Operating Systems Principles, pages 68-78, Décembre Sun Microsystems. The Java Language : A White Paper. Technical Report, Sun Microsystems, A. Tanenbaum. Systèmes d exploitation. Prentice Hall et InterEditions,

60 Références bibliographiques [Theimer85] [Wall97] M. M. Theimer, K. A. Lantz et D. R. Cheriton. Preemptable Remote Execution Facilities for the V-System. Proceedings of the 10 th ACM Symposium on Operating Systems Principles, Décembre L. Wall, T. Christiansen et R. L. Schwartz. Programmation en Perl. O Reilly International Thomson, [Wegner87] P. Wegner. Dimensions of Object-Based Language Design. OOPSLA 87 Conference Proceedings, SIGPLAN Notices, 22(12) pages , Décembre [Zajcew93] [Zayas87] [Zhou94] R. Zajcew, P. Roy, D. Black, C. Peak, P. Guedes, B. Kemp, J. Lo Verso, M. Leibensperger, M. Barnett, F. Rabii et D. Netterwala. An OSF/1 UNIX for Massively Parallel Multicomputers. Proceedings of the Winter USENIX Conference, pages , Janvier E. Zayas. Attacking the Process Migration Bottleneck. Proceedings of the 11 th Symposium on Operating Systems Principles, pages 13-24, Novembre S. Zhou, X. Zheng, J. Wang et P. Delisle. Utopia : A Load Sharing Facility for Large, Heterogeneous Distributed Computer Systems. Software Practice and Experience, Décembre

61 Bibliographie complémentaire Bibliographie complémentaire Nous proposons ici une bibliographie complémentaire qui n est pas directement liée à mes travaux mais qui est tout de même intéressante. Migration dans des systèmes à agents [Baumann97] [Cai96] [Kotz96] [Li96] [Peine97] F. Hohl, P. Klar et J. Baumann. Efficient Code Migration for Modular Mobile Agents. The 3 rd ECOOP 97 Workshop on Mobile Object Systems, T. Cai, P. A. Gloor et S. Nog. DartFlow : A Workflow Management System on the Web Using Transportable Agents. Technical Report PCS-TR96-283, D. Kotz, R. Gray et D. Rus. Transportable Agents Support Worldwide Applications. The 7 th SIGOPS European Workshop, Septembre ftp://ftp.cs.dartmouth.edu/pub/kotz/papers/kotz :agents.ps.z W. Li et D. G. Messerschmitt. Java-To-Go. H. Peine et T. Stolpmann. The Architecture of the Ara Platform for Mobile Agents. Proceedings of th 1 st International Workshop on Mobile Agent, MA 97, Avril