Brevet FR2881240A1 — publié le 20060728

ANALYSE D'ECHAPPEMENT DANS UN PROGRAMME EN LANGAGE ORIENTE OBJET POUR MACHINE VIRTUELLE A PILE L'invention concerne de façon générale les programmes informatiques, et en particulier les procédés d'analyse d'échappement dans les programmes en langage orienté objet pour machine virtuelle à pile. L'analyse d'échappement est effectuée sur un programme afin de déterminer la durée de vie d'objets. Une analyse d'échappement permet notamment des optimisations possibles lors de l'exécution, par exemple la gestion 10 mémoire en pile d'objets ou une élimination de synchronisation. Une fonction de ramasse-miettes (désignée par le terme garbage collection en langue anglaise) est intégrée dans une machine virtuelle afin de récupérer des emplacements mémoire qui ont cessé d'être utilisés par un programme. Un ramasse-miettes balaye l'ensemble des emplacements mémoire qui ont été alloués à des objets dans un espace mémoire dédié. Des emplacements devenus inutilisés sont alors identifiés. Lorsqu'un objet n'est plus pointé par un quelconque autre objet, ses emplacements sont considérés comme inutilisés. Ces emplacements mémoire sont alors marqués pour pouvoir être réalloués à un autre processus du programme. La récupération de place mémoire requiert un nombre important d'opérations et la récupération de place mémoire par le ramasse-miettes peut alors occuper une partie excessive des capacités de traitement d'un dispositif à capacité de traitement limitée. Le temps requis pour la récupération de place dans une mémoire non volatile peut également être important, du fait de leur longue durée d'écriture. L'objet de l'invention consiste à adapter les analyses d'échappement de programme dans le but de mettre en oeuvre ce type d'analyse au moyen d'un dispositif dont les capacités de traitement ne lui permettent pas avec les techniques connues d'analyser l'intégralité des méthodes du programme. L'invention vise également à garantir l'intégrité du résultat de l'analyse d'échappement. L'invention porte ainsi sur un procédé d'analyse d'échappement, comprenant les étapes consistant à : -dans un premier dispositif de traitement, réaliser une analyse statique d'échappement sur un programme en langage intermédiaire d'exécution pour machine virtuelle à pile et générer des signatures d'échappement associées à des méthodes respectives du programme en fonction de règles d'échappement prédéterminées; -dans un second dispositif de traitement muni d'une machine virtuelle à pile: - charger les signatures d'échappement générées et le programme; - réaliser une analyse statique d'échappement partielle basée sur les signatures chargées et générer, en fonction desdites règles d'échappement prédéterminées, des signatures d'échappement de test associées aux méthodes munies d'une signature d'échappement; -pour une méthode donnée, vérifier la cohérence entre sa signature d'échappement de test et sa signature d'échappement chargée. Selon une variante, le deuxième dispositif de traitement utilisé est un dispositif à capacité de traitement limitée. Selon encore une variante, une signature d'échappement générée pour une 20 méthode comprend des informations associées à ses paramètres tels que ses arguments, son objet courant et/ou son objet de retour. Selon une autre variante, l'analyse statique d'échappement partielle et la vérification de cohérence sont réalisées après le chargement du programme dans le second dispositif de traitement. Selon encore une autre variante, le programme en langage intermédiaire d'exécution est sous forme de pseudo-code binaire Java ou CLI. D'autres caractéristiques et avantages de l'invention ressortiront clairement de la description qui en est faite ci-après, à titre indicatif et nullement limitatif, en référence aux dessins annexés, dans lesquels: la figure 1 illustre schématiquement deux dispositifs de traitement mis en oeuvre dans l'invention; -la figure 2 illustre les étapes de procédé d'analyse d'un programme selon l'invention; -la figure 3 illustre des règles d'échappement sur des instructions d'un pseudo-code binaire Java; les figures 4 à 6 illustrent un code Java et l'analyse statique d'échappement effectuée sur son équivalent en pseudo-code binaire; - la figure 7 illustre une analyse statique et une vérification effectuées dans 10 un dispositif de traitement chargeant le programme. On utilisera par la suite les notions suivantes: Un objet o est dit non échappé (ou capturé) par une méthode m dans laquelle il a été alloué seulement si sa durée de vie ne dépasse pas celle de la méthode m. Une allocation de o capturée peut être détruite sans risque à la sortie de cette méthode m. Les emplacements mémoire occupés par l'objet capturé o peuvent donc être libérés à la fin de l'exécution de la méthode m. Par opposition, un objet o échappé est un objet auquel il peut potentiellement être fait référence après la fin de l'exécution de la méthode m dans laquelle il a été alloué. Un dispositif à capacité de traitement limitée désignera un dispositif de traitement dont la capacité de traitement est insuffisante pour réaliser à lui seul l'analyse statique d'échappement sur l'intégralité du programme. Un dispositif à capacité de traitement limitée présentera par exemple une mémoire vive inférieure à 32 KiloOctets et une mémoire EEPROM inférieure à 512 KiloOctets. L'invention propose un procédé d'analyse d'échappement dans lequel une analyse statique d'échappement est réalisée sur un programme en langage intermédiaire d'exécution pour machine virtuelle à pile, dans un premier dispositif de traitement. Des signatures d'échappement associées aux méthodes du programme sont générées selon des règles d'échappement prédéterminées. Le programme et les signatures d'échappement sont chargées dans un second dispositif de traitement et une analyse statique d'échappement partielle, basée sur les signatures d'échappement chargées est réalisée. Des signatures de test associées aux objets du programme chargé sont générées par les mêmes règles d'échappement prédéterminées. La cohérence entre les signatures d'échappement chargées et les signatures d'échappement de test est alors vérifiée. L'intégrité du programme chargé est ainsi vérifiée. Les signatures d'échappement chargées ne peuvent donc pas être frauduleusement utilisées pour contourner les règles de sécurité sur les références d'objets. L'invention propose un procédé d'analyse d'échappement réalisable sur 10 une forme du programme habituellement disponible et limitant les ressources nécessaires pour effectuer la vérification de cohérence d'échappement. La figure 1 illustre un exemple de système mettant en oeuvre l'invention. Un premier dispositif de traitement DTA est formé d'un ordinateur. Le dispositif DTA est connecté à un lecteur de carte à puce LEC, par l'intermédiaire duquel il peut communiquer avec le second dispositif de traitement DCTL formé d'une carte à puce. Le dispositif de traitement DTA dispose d'un programme en langage intermédiaire d'exécution, destiné à être soumis au procédé d'analyse statique d'échappement et à un chargement dans le dispositif DCTL. Un exemple de procédé mettant en oeuvre l'invention est illustré en référence à la figure 2. L'analyse d'échappement sera illustrée sur les instructions de la machine virtuelle Java (en anglais nommé bytecode Java, décrites dans la spécification nommée The Java Virtual Machine Specification écrite par Tim Lindholm et Frank Yellin aux éditions The Java Series, Addison-Wesley (1ère ed.) en 1996). A l'étape 201, le premier dispositif de traitement DTA réalise une analyse statique d'échappement sur le programme sous sa forme de pseudo- code binaire. L'analyse statique d'échappement a pour objectif de déterminer la durée de vie d'objets et vise à générer des signatures d'échappement résumant les comportements d'échappement. Pour chaque méthode m on génère deux signatures d'échappement, l'une nommée directe et notée Sem et une seconde nommée unifiée et notée [Se]m. Les signatures se focalisent sur les paramètres d'appels d'une méthode qui sont dans l'ordre: l'objet courant this , les arguments argi,..., argn ainsi que l'objet de retour retourné par la méthode que l'on nomme retu rn . L'analyse statique d'échappement réalisée dans le premier dispositif de traitement DTA peut être réalisée comme suit. L'analyse statique d'échappement établit un graphe du flot de contrôle du programme et parcourt cette représentation abstraite du programme. Un graphe des méthodes d'appels et de leurs interactions est ainsi établi afin de réaliser une analyse inter-méthodes et un graphe d'exécution de chaque méthode est établi afin de réaliser une analyse intraméthodes. Des procédés connus d'estimation de graphe de flot de contrôle de langages orientés objets peuvent être utilisés à cet effet. L'analyse statique d'échappement coordonne une analyse intra-méthodes et une analyse inter-méthodes. En effet, pour déterminer le comportement d'une méthode m faisant appel à une autre méthode m', il est nécessaire d'étudier également le comportement de cette autre méthode. Des hypothèses d'échappement d'objets sont adoptées en début d'analyse (les hypothèses de départ supposeront que tous les objets sont capturés), puis ces hypothèses sont mises à jour de façon incrémentale durant l'analyse inter-méthodes. Lorsque les hypothèses d'échappement convergent vers un point fixe, l'analyse statique d'échappement est interrompue. On va par la suite détailler l'analyse intra-méthode réalisée. L'analyse utilise un interpréteur abstrait associant des règles d'évaluation pour chaque instruction du programme. L'interpréteur abstrait exécute les instructions de la machine virtuelle Java en suivant le flot de contrôle du programme. L'analyse intra-méthode évalue les instructions d'une méthode de manière isolée, méthode par méthode, sans avoir connaissance du comportement des autres méthodes. L'interpréteur peut être représenté par un ensemble de relations de transition: i: (R, P) '(R',P') où i est l'instruction évaluée, R et P représentent respectivement la valeur des registres et de la pile avant l'exécution de i, et R' et P' leur valeur après son exécution. Par simplification les registres et les cellules de la pile manipulent des valeurs que l'on note v. Ces valeurs regroupent à la fois les types de bases (entier, booléen...) ainsi que les références d'objets ou de tableaux. Par exemple, l'instruction aload_k duplique le contenu du registre k en 10 sommet de pile: aload_k: (R{k = v}, P) (R{k = v}, P.v) Après exécution de l'instruction, le registre Rk et le sommet de pile contiennent donc la même valeur v. L'instruction inverse, astore_k, dépile la valeur v en sommet de pile pour la placer dans le registre k: astore_k: (R, P.v) (R{k v}, P) v est ainsi défini comme étant l'ensemble des références contenues dans un registre ou une cellule de la pile en un point p de l'exécution du programme. Une analyse d'alias entre les registres suit le contenu des registres en chaque point p de l'exécution du programme. Ces références r sont issues des allocations, et marquées par le point du programme qui les ont créées rp. À chaque instruction du pseudo-code binaire Java, une règle d'échappement est associée. Une allocation en p empile sur la pile une référence définie à capturée rp: 1. (le signe 1 désignera par la suite le plus petit élément du treillis soit une référence définie comme capturée). new: (R, P) = (R, P.v) tel que v = {rp} et rp: Une instruction a potentiellement plusieurs prédécesseurs. Ainsi, l'état des registres et de la pile avant évaluation de i est l'union (notée U) des états des prédécesseurs de i après leur évaluation. Si on désigne instr(p) pour l'instruction au point de programme p, in(p) l'état avant et out(p) celui après, le système d'équations de l'analyse d'échappement pour chaque point p du programme est le suivant: instr(p) : in(p) out(p) in(p) = U(out(q)), q étant un prédécesseur de p; avec comme point de départ pour in(po) les données de la signature d'échappement Sem (échappement des paramètres d'appels et connexion entre paramètres d'appels). L'unification de deux valeurs v u v' est l'union de leur ensemble, sans doublons. Les équations sont ensuite résolues par un algorithme standard itératif 15 jusqu'à atteinte du point fixe. Par simplification, une liste globale des valeurs L issues des allocations est maintenue pendant l'analyse (au départ de l'analyse, cette liste est définie à vide) . Lorsque la référence d'une allocation s'échappe, elle est enlevée de la liste. L correspond alors à l'ensemble des références capturées L _ {rp I rp: 11. Selon une optimisation détaillée ultérieurement, les allocations 20 correspondantes à ces références peuvent être gérées par une gestion en pile. En plus des registres et de la pile, on construit un graphe de connexion G qui indique les connexions mémoires existantes entre les valeurs références manipulées par le programme. La structure de données G permet de traiter les affectations. Soit V l'ensemble des valeurs, on définit G tel que G: V -y D(V) où D(V) est l'ensemble des parties de V. Le graphe est mis à jour lors des affectations putfield et aastore en établissant une connexion entre la valeur destination vd 2881240 et la valeur affectée va. Cette connexion est rajoutée à celles déjà existantes depuis vd. L'instruction aretu rn met à jour G afin d'établir la signature d'échappement sur les connexions entre paramètres pour l'objet retourné. En ce qui concerne la lecture d'un champ d'objet ou d'une cellule de tableau, instructions getfield et aaload, les valeurs pointées par v notées G(v) sont montées en somment de pile. L'échappement d'une valeur v lors de l'évaluation d'une instruction i est désignée par esc(v) = T telle que d rp E v, rp = T. De plus, l'échappement d'une valeur v fait échapper par atteignabilité toutes les valeurs accessibles depuis v telle que esc(G(v)) = T. La figure 3 illustre des règles d'échappement sur le pseudo-code binaire Java appliqué à un certain nombre d'instructions et permettant de générer les signatures d'échappement Sem et [Se]m. Quelles que soient les informations de l'analyse intra-méthode, le fonctionnement de l'analyse inter-méthodes est similaire. L'analyse interméthodes calcule une signature pour chaque méthode ayant subi une analyse intra-méthode, cette signature étant valable quel que soit son contexte d'appel. L'analyse inter-méthodes est une analyse statique par interprétation abstraite interagissant avec celle de l'analyse intraméthode. Les données des signatures sont des semi-treillis. Leurs structures sont issues de celles spécifiées dans l'analyse intra-méthode. Pour la génération des signatures, au départ, on définit la signature d'échappement au plus petit élément du treillis. Ensuite, l'algorithme inter-méthodes traite les méthodes les unes après les autres. Pour chaque méthode, on effectue une analyse intra-méthode dont le résultat permet de donner la nouvelle signature d'échappement. Lors d'une analyse intra-méthode de m, soit in(Sem) sa signature en entrée et out(Sem) celle en sortie, si in(Sem) C out(Sem) (au moins un des paramètres de la signature a progressé dans son semi-treillis) alors une seconde analyse intraméthode doit être effectuée sur m ainsi que sur les méthodes appelant m. Ainsi, tant que le point fixe global des signatures n'est pas atteint, on continue l'analyse inter-méthodes. L'interaction entre les analyses inter-méthodes et intra-méthode permet de générer le point fixe des signatures d'échappement Sem et [Selim. On va maintenant définir la signature d'échappement sur les paramètres d'appels. Soit Sem' la signature d'échappement de la méthode m' appelée pendant l'analyse de m. On définit cette première signature sur les paramètres d'appels par: V kE 0... n 1 Sem '(vpar_k) = T Si Vpar_k s'échappe par m' 1 sinon Le point de départ de l'analyse intra-méthode pour une méthode m se base sur sa propre signature d'échappement Sem: in(po) = ((Vpar_o, ..., Vpar_n-1, ve, ..., Ve), E) tel que esC(Vpar_k) = Sem(Vpar_k) pour k = 0...n 1 et esc(v ) = avec Vpar_k = {rpar_k} et Ve = {} où Vpar_k symbolise la référence passée en argument qui est encapsulée dans la structure de valeur afin d'effectuer l'analyse d'alias sur les registres. Au départ, chacune de ses références symboliques sur les paramètres est ajoutée à la liste L. À la fin d'une passe d'analyse intra-méthode, les paramètres restant dans la liste L servent à mettre à jour la nouvelle signature. Lors d'un appel de méthode, on applique une signature d'échappement sur les arguments de la pile. Lorsque l'on connaît avec exactitude la méthode appelée (invokespecial et invokestatic) la signature calculée Sem' est appliquée sur les éléments de la pile. Dans le cas des méthodes virtuelles (invokevirtual et invokeinterface), on applique la signature unifiée notée [Se]m " calculées depuis les signatures des méthodes m" appelables telle que: [Se] m '(Vpar_k) = v m" appleables Sem "(Vpar_k) On va maintenant définir la signature d'échappement sur les connexions entre les paramètres d'appels. Cette signature sur les connexions entre les paramètres étend la signature précédente sur l'échappement des paramètres. Cette signature expose en dehors d'une méthode m les connexions entre les paramètres d'appels établies pendant l'analyse intra-méthode: T si il existe une connexion entre Vpar_k et Vpa_j 1 sinon Le point de départ de l'analyse intraméthode devient: in(po) = ((Vpar_o, ..., Vpar_n-1, Ve, ..., Ve), E) tel que esc(vpar_k) = Sem(vpar_k) pour k,j = O...n 1 et esc(vE) = avec Vpar_k = {rpar_k} , VE = {} et G(rpar_k)={rpar j} lorsque Sem(G(Vpar_k, Vparj))= T La figure 4 illustre un exemple de code Java dans lequel l'allocation au point 1. est échappée et dont l'allocation au point 2. est non échappée. Les figures 5 et 6 illustrent l'utilisation des règles d'analyse statique, règles décrites en liaison avec la figure 3, sur chaque instruction des méthodes du pseudo-code Java associé. La signature Se de la méthode id()LC prise en entrée est: 1 01 sans connexion. A la sortie, la signature Se de id()LC vaut 1 ()1 avec une connexion de rretum vers rthis. La colonne de droite indique l'évolution de la liste L et du graphe de connexion G. d k, j E 0... n 1 Sem '(G(Vpar_k, Vparj)) = La signature Se de la méthode factory()LC prise en entrée est: 1 01 sans connexion. L'analyse de la méthode factoryOLC fait appel à la signature Se de idOLC. La signature Se de sortie de la méthode factoryOLC vaut: 1 01 sans connexion, l'allocation du point p4 est nonéchappée et celle du point po est échappée. En effet, au moment de l'instruction areturn lors de l'appel à la méthode idOLC au point pu), la référence rinvoke_plo s'échappe et par atteignabilité, G(invoke_plo) ={rpo} fait échapper rpo. Suite à l'analyse d'échappement, des signatures d'échappement sont ainsi 10 obtenues pour au moins certaines méthodes à l'étape 202. Comme détaillé dans les exemples ci-dessus, pour une méthode prédéterminée, les signatures d'échappement comprennent avantageusement des informations d'échappement concernant différents paramètres: ses arguments, son objet courant ou son objet renvoyé. Une signature d'échappement peut ainsi comprendre les informations suivantes: -des définitions d'échappement définissant si un objet est capturé par la méthode pour tous ses paramètres; -une référence de liaison mémoire définissant si, pour chaque combinaison de deux paramètres définis dans la signature, l'un fait référence à l'autre dans le programme. Ces informations permettent de déterminer le cas d'échappement suivant: si un objet est référencé par un objet s'échappant, alors il s'échappe également. Les appels de méthodes virtuelles peuvent rendre la prédiction effectuée durant l'analyse statique d'échappement peu précise. Pour remédier à cela, on a généré pour chaque méthode la signature d'échappement directe Sem et la signature d'échappement unifiée [Se] m. La signature d'échappement directe concerne une trace d'exécution effectuée durant l'analyse statique: cette signature pourra être utilisée par le second dispositif DCTL si le type de l'objet est exact. Le type de l'objet est exact, si au cours de sa durée de vie, son type dynamique est égal à son type déclaré statistiquement. La signature d'échappement unifiée réalise une prédiction au pire cas, par unification de différentes traces d'exécution possibles: cette signature d'échappement pourra être utilisée par le second dispositif DCTL si, lors d'un appel de méthode, le type d'un objet a varié depuis sa création. La signature d'échappement unifiée est par exemple générée en réalisant l'unification des signatures d'échappement directes pour l'ensemble des méthodes appelables en ce point du programme. Ainsi, même si la signature d'échappement unifiée ne correspond pas précisément aux conditions d'exécution du programme, ses indications d'échappement sont suffisamment approchées pour ne pas déterminer un objet capturé de façon erronée. La signature d'échappement unifiée est générée en parcourant l'arborescence d'héritage et la surcharge de méthode. Bien entendu, l'utilisation de la signature d'échappement unifiée permet de déduire un nombre plus réduit d'objets capturés par rapport à l'utilisation de la signature d'échappement directe. Lors de l'exécution, le dispositif DCTL utilisera soit l'une ou l'autre des signatures d'échappement en fonction des appels statiques déclarés dans le pseudo-code ou en fonction d'informations de type obtenues d'un vérifieur de pseudo-code, comme détaillé ultérieurement. L'homme du métier saura limiter le nombre de méthodes à optimiser pour conserver un programme à charger de taille raisonnable. Ainsi, l'homme du métier pourra réserver la génération de signatures d'échappement aux méthodes présentant les meilleures perspectives d'optimisation lors de l'exécution. L'étape 203 comprend un chargement du programme et des signatures d'échappement dans le dispositif de traitement DCTL, une analyse statique partielle d'échappement conduisant à la génération de signatures d'échappement de test et une vérification de cohérence entre les signatures d'échappement chargées et les signatures d'échappement de test. L'analyse statique partielle d'échappement utilise les mêmes règles d'analyse d'échappement que celles utilisées dans l'analyse statique du dispositif DTA. Comme illustré à la figure 7, pour effectuer la vérification de cohérence d'échappement, les signatures d'échappement chargées sont utilisées comme hypothèses pour une analyse statique d'échappement intra-méthode à l'étape 204. Lors de l'analyse intra-méthode de la méthode m, sa signature chargée est utilisée comme sa signature en entrée in(Sem) est prise en entrée et la signature out(Sem)=Stm est obtenue en sortie comme signature de test. Lors d'un appel à la méthode m', la signature Sem' chargée est utilisée pour poursuivre l'analyse intra-méthode sur m. On compare alors à l'étape 205 la signature d'échappement chargée à la signature d'échappement de test obtenue. Si l'ensemble des échappements définis dans la signature chargée est inclus dans l'ensemble des échappements de définis dans la signature de test Stm, on considère qu'il y a cohérence entre la signature d'échappement chargée et la signature d'échappement de test: l'utilisation de la signature d'échappement chargée ne risque pas de déterminer de façon erronée un objet comme capturé par la méthode. On peut ainsi vérifier l'intégrité du programme et des signatures chargées. Comme seule l'analyse intra-méthode est effectuée par le dispositif DCTL, la quantité de ressources dont il doit disposer pour mettre en oeuvre l'analyse statique partielle et la vérification de cohérence d'échappement peut être limitée. L'intégrité du programme peut donc être vérifiée dans un temps raisonnable même avec un dispositif à ressources limitées, tel qu'une carte à puce. Le dispositif de traitement DTA présente ainsi avantageusement des capacités de traitement nettement supérieures à celles du dispositif de traitement DCTL. Des signatures directes concernant les méthodes du programme peuvent être générées dans le dispositif DTCL par un vérifieur de pseudo-code binaire disponible le cas échéant. La vérification peut alors être effectuée en prenant en compte soit la signature d'échappement directe chargée, soit la signature d'échappement unifiée chargée. Lorsqu'une incohérence est détectée lors de la vérification, on peut prévoir que la machine virtuelle bloque la poursuite du chargement du programme, bloque l'exécution ultérieure du programme ou bloque la réalisation d'une optimisation du programme basée sur les signatures d'échappement. On peut également envisager de limiter l'optimisation aux méthodes pour lesquelles la vérification de cohérence a donné un résultat favorable. Bien qu'il soit possible de réaliser la vérification de cohérence d'échappement lors de l'exécution du programme, on privilégiera en pratique une vérification de cohérence d'échappement réalisée durant ou juste après le chargement du programme dans le dispositif de traitement DCTL. Bien qu'on ait représenté un chargement du programme depuis le dispositif de traitement réalisant la première analyse statique d'échappement, le chargement sera généralement effectué depuis une autre machine sur une ligne de fabrication. A l'issue du procédé selon l'invention, la machine virtuelle du dispositif de traitement du dispositif DCTL exploite les signatures d'échappement chargées afin de déterminer des optimisations de l'exécution du programme. La machine virtuelle peut notamment déterminer, sur la base des signatures d'échappement chargées, les objets capturés qui pourront être gérés en mémoire avec une fonction différente de la gestion par ramasse- miettes de la machine virtuelle. Afin d'alléger la gestion mémoire, on peut notamment prévoir de gérer ces objets par allocation en pile. L'allocation et la désallocation des objets capturés en pile suit la pile des méthodes d'appel. L'allocation de chaque objet capturé se fait en sommet de pile. La désallocation est effectuée de façon globale à la sortie de la méthode dans laquelle les objets capturés ont été alloués. La machine virtuelle peut encore être utilisée pour l'élimination de synchronisations à partir des signatures d'échappement. Un objet capturé par une méthode étant accédé par un unique processus, il ne nécessite alors pas de mécanismes de synchronisation d'accès (gestion de verrous et de mécanismes d'exclusion mutuelle). L'élimination de synchronisation élimine les éléments de synchronisation inutiles afin d'optimiser la gestion de l'ordonnancement et de la concurrence d'accès dans le dispositif DCTL. La machine virtuelle réalise l'exécution du programme en prenant en 5 compte les optimisations déterminées précédemment. REVENDICATIONS 1. Procédé d'analyse d'échappement, caractérisé en ce qu'il comprend les étapes consistant à : -dans un premier dispositif de traitement, réaliser une analyse statique d'échappement sur un programme en langage intermédiaire d'exécution pour machine virtuelle à pile (201) et générer des signatures d'échappement associées à des méthodes respectives du programme en fonction de règles d'échappement prédéterminées (202) ; dans un second dispositif de traitement muni d'une machine virtuelle à pile: -charger les signatures d'échappement générées et le programme (203) ; -réaliser une analyse statique d'échappement partielle (204) basée sur les signatures chargées et générer, en fonction desdites règles d'échappement prédéterminées, des signatures d'échappement de test associées aux méthodes munies d'une signature d'échappement; -pour une méthode donnée, vérifier (205) la cohérence entre sa signature d'échappement de test et sa signature d'échappement chargée. 2. Procédé selon la revendication 1, dans lequel le deuxième dispositif de 25 traitement utilisé est un dispositif à capacité de traitement limitée. 3. Procédé selon la revendication 1 ou 2, dans lequel une signature d'échappement générée pour une méthode comprend des informations associées à ses paramètres tels que ses arguments, son objet courant et/ou son objet de retour. 10 15 20 4. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'analyse statique d'échappement partielle et la vérification de cohérence sont réalisées après le chargement du programme dans le second dispositif de traitement. 5. Procédé selon l'une quelconque des revendications précédentes, dans lequel le programme en langage intermédiaire d'exécution est sous forme de pseudo-code binaire Java ou CLI.