PODUS

PODUS [SF93], acronyme de “Procedure-Oriented Dynamic Update System”, est un système qui a adressé l’adaptation des procédures en exécution. Proposé en 1993, PODUS permet l’adaptation incrémentale des procédures en mémoire. Il a résulté de plusieurs travaux de Mark Segal et Ophir Frieder [SF89, FS91, SF93]. Plusieurs versions de la même procédure peuvent coexister. Chacune est chargée dans un espace mémoire séparé, avec sa propre table de liaisons. Tous les appels entre les procédures sont indirects et passent forcément par cette table.

5.2.1 Adaptation des procédures

Une procédure ne peut être changée que si elle est inactive. Une procédure est inactive si :

elle n’est pas en cours d’exécution,

aucune des procédures, susceptibles d’être appelées par sa nouvelle version, n’est en cours d’exécution. Ceci est nécessaire car, comme nous l’expliquerons dans la suite, l’adaptation d’une procédure entraîne automatiquement l’adaptation de

toutes les procédures que sa nouvelle version doit appeler. Les procédures susceptibles d'être appelées sont déterminées en analysant le code de la nouvelle version de la procédure.

Chaque procédure comprend deux parties :

la spécification du comportement (l’interface), l’implémentation.

L’adaptation d’une procédure se traduit par le changement de la liaison entre sa spécification et son implémentation. Si la modification doit aussi affecter la spécification, une

inter-p océdurer est nécessaire pour transférer les appels et retourner les résultats.

5.2.2 Utilisation des inter-procédures

PODUS permet que la nouvelle version d’une procédure, utilise une signature différente de l’ancienne. Pour garder la compatibilité entre les différentes procédures de l’application et la nouvelle version, le concept des inter-procédures a été introduit. Une inter-procédure est une procédure, écrite par le programmeur, et destinée à remplacer l’ancienne version dans le même espace mémoire. La Figure 18 illustre l’interaction entre une procédure de l’application et une nouvelle version d’une procédure. Comme le montre la Figure 18, la procédure Pi tente d’appeler la procédure Pj qui a été adaptée par une nouvelle version Pj’, ayant une signature différente. Une inter-procédure prend alors la place de la procédure Pj dans le même espace mémoire. Son rôle est de recevoir et de rediriger vers Pj’, les appels initialement envoyés vers

Pj. L'inter-procédure est responsable, éventuellement, de récupérer le résultat retourné par

Pj’, de le transformer en cas de besoin, avant de le transférer à Pi.

5.2.3 Architecture du système

Comme illustré par la Figure 19, PODUS comporte deux composants principaux : un

shell et un processeur d’adaptation. Le shell (ush) fournit un ensemble de commandes, permettant à l’utilisateur de charger, d’exécuter et d’adapter dynamiquement les procédures d’une application. Le processeur d’adaptation (pup) contrôle le processus dans lequel s’exécute l’application. Il fournit aussi les primitives nécessaires pour réaliser l’adaptation. Le processeur d’adaptation reçoit et exécute les commandes, envoyées à travers le shell. Il renvoie éventuellement des notifications.

Figure 19. Architecture de PODUS

L’utilisateur peut lancer l’adaptation à tout moment. Une fois la requête d’adaptation reçue, le système commence d’abord par déterminer l’ensemble S des procédures actives. Une procédure Pi ne peut être adaptée que si elle ne fait pas partie de l'ensemble S. Une fois adaptée, la procédure Pi est marquée comme étant une nouvelle version.

Les procédures actives sont déterminées en parcourant la pile d’exécution et le graphe d’appel entre les procédures. Une telle information permet de déterminer le moment où une procédure peut être adaptée. Cependant, il n’est pas possible dans tous les cas de déterminer l’ensemble des procédures actives, car les appels des procédures peuvent dépendre d’un facteur externe (application de contrôle par exemple). C’est ce que les concepteurs appellent

dépendances sémantiques, par opposition aux dépendances syntaxiques, reliant directement les procédures entre elles. Les dépendances syntaxiques peuvent être déterminées à partir du code de l’application. En contre partie, les dépendances sémantiques ne peuvent pas être déterminées automatiquement. L’utilisateur doit les spécifier, explicitement, avant de lancer l’adaptation. Quand une procédure est adaptée, le système adapte automatiquement toutes les procédures, syntaxiquement ou sémantiquement liées à la procédure adaptée.

Exemple d’utilisation

Imaginons que l’on a dans une application une procédure trier_Entiers qui trie des entiers. On souhaite, par exemple, manipuler des réels au lieu des entiers. Il faut donc adapter la procédure trier_Entiers par une procédure qui fait le tri des réels (trier_Reels). Puisque la spécification de la procédure a changé, une inter-procédure est nécessaire. Le code de l'inter-procédure peut avoir la forme suivante :

interprocedure trier_Entiers(data : array of integer);

var

real_data : array of real;

{

real_data := convert_to_real(data); trier_Reels(real_data);

data := convert_to_integer(real_data);

}

L'inter-procédure précédente est nécessaire pour que les procédures existantes puissent continuer à s’exécuter normalement. Une procédure qui tente d’appeler trier_Entiers tombe sur l’inter-procédure qui la remplace. Cette dernière transforme d’abord le tableau des entiers, reçu en paramètres, en un tableau de réels. Elle appelle, ensuite, la procédure de tri des réels (trier_Reels). Enfin, elle retourne le résultat à l’appelant, après l'avoir transformé.

5.2.4 Discussion

PODUS est un système qui supporte l'adaptation dynamique des procédures. Il ne se contente pas seulement d'assurer l'adaptation de l'implémentation des procédures, mais il fournit en plus, un mécanisme qui permet d'adapter même leur spécification (le mécanisme des inter-procédures). Une procédure ne peut être adaptée que si elle n'est pas active. Si une application n'est pas bien modélisée, ou si une procédure doit s'exécuter pour longtemps, l'adaptation risque d'être fortement retardée.

Les inter-procédures constituent un bon moyen pour l’adaptation transparente des applications. En contre-partie, leur invocation systématique, à chaque appel, peut jouer un rôle important dans la dégradation des performances du système. Ceci est d'ailleurs le problème des techniques d'interposition en général (aspects, proxys, contenaires…).

6

6 SS

Plusieurs solutions de reconfiguration considèrent le module comme unité de modification. Un tel choix est justifié par plusieurs raisons :

les langages de programmation, utilisés pour développer les applications dynamiquement adaptables, sont de nature modulaire,

le plus souvent, dans ces langages, le module constitue l’unité d’abstraction et d’encapsulation des structures de données, et des procédures qui les manipulent, le module constitue également, le plus souvent, l’unité de compilation séparée. Dans la sous-section suivante, nous présentons Polylith, un système de reconfiguration modulaire, que nous avons étudié dans cette thèse.