Brevet FR2849229A1 — publié le 20040625

La présente invention concerne un procédé de compactage de programme par suppression dynamique de code. Elle a plus particulièrement pour objet, mais non exclusivement, de compacter des programmes qui s'exécutent sur des plates-formes disposant de faibles 15 ressources mémoire; c'est le cas par exemple des petits systèmes embarqués tels que les cartes à puce et les terminaux de paiement. Ce procédé est particulièrement adapté à la libération de ressources mémoire dans ces systèmes et par conséquent autorise la réutilisation de ces dites 20 ressources mémoire. Il comprend quatre étapes: * la détermination de fragments d'un programme qui, sous certaines 25 hypothèses, peuvent être supprimés sans en modifier la sémantique, * l'instrumentation d'un programme pour marquer des fragments supprimables et les conditions sous lesquelles ils peuvent être supprimés, * la transformation éventuelle du programme pour augmenter l'économie 30 mémoire qu'apportera une suppression des fragments supprimables, * la structuration en mémoire d'un programme avec fragments supprimables et la suppression effective de ces fragments pour permettre la réutilisation des zones mémoire libérées correspondantes. Ce compactage de programme par suppression dynamique de code est particulièrement utile dans les deux cas de figure suivants: * si, au cours de l'exécution d'un programme, un ou plusieurs fragments de ce programme ne sont plus utiles dans la suite de l'exécution, ils 10 peuvent être totalement supprimés La place mémoire correspondante peut être ainsi récupérée pour d'autres usages, sans incidence sur le comportement du programme. * la suppression d'un ou de plusieurs fragments de programme peut aussi être forcée à tout moment Le ou les fragments supprimés, ainsi que les 15 portions de programme qui exploitaient ces fragments supprimés, sont alors remplacés par du code qui signale la suppression desdits fragments, afin qu'une erreur soit notifiée dans le cas o l'exécution du programme nécessiterait lesdits fragments Suite à la suppression de code, le programme peut ainsi perdre certaines fonctionnalités Le 20 choix de fragments de programme à supprimer réalise donc un compromis entre les fonctionnalités offertes par le programme et la taille mémoire qu'il occupe. La suppression de fragments de programmes peut être opérée autant de fois 25 que nécessaire au cours d'une exécution pour gagner davantage de place mémoire. La suppression de fragments de programmes a également un intérêt sécuritaire: si les circonstances veulent que des fonctionnalités d'un 30 programme doivent devenir définitivement inopérantes pour des raisons de sécurité, il est plus sr de les supprimer effectivement de la mémoire du système que de mettre en place un contrôle d'accès. Le besoin d'économiser la mémoire n'est pas la seule raison qui fait des petits 5 systèmes embarqués une bonne cible pour le compactage par suppression de code; la nature même des programmes qui s'exécutent sur ces systèmes y contribue également En effet, il est fréquent que des programmes chargés sur ces systèmes ne soient exécutés qu'une unique fois Ce sont toutefois le plus souvent des programmes sans terminaison véritable qui réagissent sans fin à 10 des événements et des commandes qui leur sont soumis Or le cycle de vie de ces programmes passe souvent par des phases irréversibles d'initialisation préalable Par conséquent, les fragments de programmes qui réalisent ces phases d'initialisation deviennent inutiles une fois les initialisations effectuées, et peuvent donc être supprimés. Deux cas courants de telles phases d'initialisation sont dans le cas de la carte à puce: l'installation, qui crée en mémoire un exemplaire exécutable d'un programme, et lapersonnalisation, qui configure cet exemplaire exécutable de programme pour un utilisateur particulier. 20 Par exemple, dans les systèmes qui acceptent des programmes "Java Card", langage employé couramment sur les cartes à puce, l'installation est effectuée par l'appel d'une méthode (routine) réservée à cet usage unique, nommée "install" Une fois cette méthode appelée, son contenu n'est plus jamais 25 exécuté, sauf pour créer un nouvel exemplaire du même programme Sous l'hypothèse, très fréquente, que le système ne devrajamais exécuter qu'un seul exemplaire de ce programme, le contenu de la méthode "install" peut être totalement supprimé, de même que toute autre méthode auxiliaire appelée uniquement par "install" (et non par d'autres méthodes du programme). La situation est identique pour la personnalisation La seule différence, dans le cas de "Java Card", est que les fragments de code responsables de la personnalisation ne sont pas nécessairement identifiables par une méthode particulière Néanmoins, une extension très répandue du système "Java Card", 5 nommée "Open Platform", introduit une méthode, nommée "process Data", qui n'est appelée que dans la phase de personnalisation Une fois la personnalisation terminée, cette méthode peut donc aussi être supprimée, au même titre qu"'install" pour la phase d'installation, sous une hypothèse identique. Dans le cas o l'exécution d'un fragment de programme supprimé resterait matériellement possible bien qu'interdite par hypothèse, il est recommandé de remplacer le fragment supprimé par du code qui signale une erreur Dans le cas de "Java Card", le code supprimé peut être remplacé, qu'il recouvre le 15 contenu complet d'une méthode ou non, par une levée d'exception. Il s'avère que la suppression dynamique de code pose néanmoins plusieurs questions: * la structuration d'un programme en mémoire pour permettre la 20 libération de fragments, * la détermination de fragments de code supprimables dans un programme, * l'instrumentation du programme pour signaler les fragments supprimables, * la transformation éventuelle du programme pour optimiser les fragments supprimables, * la prise de décision de suppression de ces fragments, * la suppression effective de ces fragments, selon leur forme, * la restructuration éventuelle du programme résultant pour accroître la 30 possibilité de réutilisation des zones mémoire ainsi libérées. Préalablement il faut rappeler les diverses fonctionnalités qui peuvent être offertes par les gestionnaires mémoire présents dans les systèmes d'exécution. Il en existe quatre grands types principaux: * Allocation / libération Une plate-forme ordinaire d'exécution de programme est généralement munie d'un gestionnaire mémoire qui comporte au moins deux fonctionnalités: ( 1) allouer un bloc de mémoire, et ( 2) libérer un bloc de mémoire précédemment alloué. Quand un bloc est libéré, la zone mémoire correspondante peut être 10 réexploitée pour d'autres usages, notamment pour une nouvelle allocation mémoire Par exemple, dans les systèmes d'exploitation de type "Unix", la fonction "malloc" alloue un bloc mémoire d'une taille donnée et retourne un pointeur vers le début du bloc, et la fonction "free" libère un bloc donné. * Retaillage Les gestionnaires mémoire comportent également souvent des fonctionnalités de retaillage d'un bloc mémoire précédemment alloué, en réduisant la taille du bloc par la fin Certains systèmes permettent aussi parfois un retaillage en augmentant la taille d'un bloc par la fin Un bloc peut être physiquement déplacé ou non en mémoire 20 pour permettre ce retaillage Par exemple, dans les systèmes de type "Unix", la fonction "realloc" effectue une réduction (ou un accroissement) de la taille d'un bloc par la fin La réduction de la taille du bloc alloué permet ainsi de supprimer un fragment final et de libérer la mémoire correspondante pour qu'elle puisse être réutilisée par le 25 système. * Découpage dynamique Plus rarement, les gestionnaires mémoire permettent aussi de découper dynamiquement en plusieurs fragments un bloc mémoire précédemment alloué, comme si autant de blocs avaient initialement été alloués séparément Des fragments choisis 30 peuvent ainsi être libérés et réexploités par le système. Défragmentation Certains gestionnaires mémoire effectuent également, de manière transparente ou non pour l'utilisateur, une défragmentation de la mémoire Cette opération consiste à déplacer les blocs mémoire alloués pour les regrouper La défragmentation permet 5 de réduire le nombre de petits interstices de zones libre entre blocs mémoire alloués, qui sont difficilement réutilisables. Le déplacement de blocs mémoire alloués induit toutefois certaines contraintes concernant les pointeurs vers l'intérieur de blocs En particulier, 10 si des déplacements de portions de programme ont lieu, notamment après une phase éventuelle d'édition de liens, un relogeage des adresses et des déplacements de sauts peut être nécessaire. Il s'avère que pour permettre la suppression de fragments d'un programme, et 15 surtout la réutilisation efficace de la mémoire correspondante, il faut structurer le programme en mémoire à bon escient Quatre cas typiques de gestion de la représentation en mémoire d'un programme sont à considérer: la préfragmentation statique (avant l'exécution) d'un programme, la fragmentation dynamique (après l'exécution), la réduction dynamique de taille 20 de blocs, et la restructuration de programme après suppression de fragments. * Préfragmentation statique Si, lors du chargement d'un programme, le système a connaissance des fragments qui pourront être supprimés dans le futur, il peut structurer le programme en mémoire en plusieurs 25 blocs, utilisant pour cela son mécanisme ordinaire d'allocation de mémoire Un espace mémoire individuel est dans ce cas alloué pour chaque fragment supprimable, qui peut ainsi être libéré séparément, sans impact sur le reste du programme. * Fragmentation dynamique Si le programme n'a pas reçu de 30 structuration particulière lors de son chargement, des fragments peuvent néanmoins être signalés comme supprimés au cours de l'exécution Pour que les zones mémoire correspondantes puissent être réutilisées, le système peut effectuer un découpage dynamique du bloc mémoire alloué initialement pour le programme et se ramener ainsi au cas de figure ci- dessus d'un programme préfragmenté. * Réduction dynamique de taille de blocs Cependant, tous les systèmes ne disposent pas d'un gestionnaire mémoire assez puissant pour réaliser la fragmentation dynamique Il est toutefois un cas particulier que savent généralement traiter des systèmes avec gestion mémoire simple: c'est lorsque le fragment mémoire à supprimer est 10 situé à l'extrémité finale du bloc alloué pour le programme Dans ce cas, il suffit que le système permette un réajustement de la taille des blocs mémoire déjà alloués La réduction de la taille du bloc alloué pour le programme permet ainsi de supprimer le fragment final et de libérer la mémoire correspondante pour qu'elle puisse être réutilisée 15 par le système. Défragmentation Il est également possible de défragmenter dynamiquement et explicitement un bloc programme o des zones de code ont été supprimées, sans passer par l'intermédiaire du gestionnaire mémoire Cette opération consiste à assembler certaines des portions 20 de programme restantes après suppression de manière à former un ou des blocs compacts, continus, sans région libre enclavée Cette technique est utile dans plusieurs cas de figure Elle est tout d'abord applicable dans des systèmes dont le gestionnaire mémoire ne permet pas une fragmentation dynamique arbitraire mais simplement un 25 retaillage des blocs mémoire alloués: les portions de programme restantes sont assemblées en un groupe compact en début du ou des blocs et la taille du ou des blocs est ajustée à leur contenu La défragmentation peut aussi être utile plus généralement pour accroître la possibilité de réutilisation des zones mémoire libérées En effet, de 30 nombreuses petites zones sont plus difficiles à réutiliser qu'une unique grande zone, qui peut éventuellement être redécoupée Il faut toutefois noter que le déplacement de portions de programme en mémoire peut nécessiter de reloger le code résultant Par exemple, les adresses ou les déplacements des sauts interblocs doivent être recalculés C'est une tâche délicate à effectuer, tant sur le langage machine d'un 5 microprocesseur réel que sur le langage d'une machine virtuelle Mais si des routines entières sont supprimées dans un programme, reloger le code restant est souvent beaucoup plus facile car les informations à mettre à jour concernent alors davantage les adresses, déplacements et indices qui permettent d'identifier les routines plutôt que les sauts dans 10 le corps des routines même. Il s'avère que la détermination de fragments supprimables peut être effectuée de trois manières: 1 Un programmeur, qui a connaissance du cycle de vie du programme, sait, à partir de quelles étapes d'exécution, quels fragments de programmes peuvent être considérés comme supprimables. 2 Suivant les langages, des fragments d'un programme sont supprimables par 20 construction, comme c'est le cas pour "install" et "process Data" en "Java Card". 3 Enfin un traitement automatique de programme permet de déterminer des fragments de codes qui ne sont matériellement plus utiles à partir de 25 certains points et conditions d'exécution: ce mode de détermination constitue la première étape du procédé décrit ci-après. Conformément au procédé selon l'invention, le compactage de programme par suppression dynamique de code s'effectue suivant les quatre étapes suivantes: 30 * la détermination de fragments d'un programme qui, sous certaines hypothèses, peuvent être supprimés sans en modifier la sémantique, * l'instrumentation d'un programme pour marquer des fragments supprimables et les conditions sous lesquelles ils peuvent être supprimés, * la transformation éventuelle du programme pour augmenter l'économie mémoire qu'apportera une suppression des fragments supprimables, * la structuration en mémoire d'un programme avec fragments supprimables et la suppression effective de ces fragments pour permettre la réutilisation des zones mémoire libérées correspondantes. Premièrement, la détermination de fragments d'un programme supprimables est basée sur l'analyse statique de programme. L'analyse statique de programme désigne un ensemble de techniques de traitement automatique de programme qui permettent de déterminer des 15 propriétés concernant l'exécution d'un programme sans avoir à l'exécuter véritablement Un exemple extrêmement répandu d'analyse statique est l'interprétation abstraite, qui étudie des approximations de l'exécution d'un programme. La détermination automatique de fragments de programmes supprimables par analyse statique de programme pourra être mise en oeuvre selon la séquence opératoire suivante: * modélisation, sous forme d'un état abstrait, de l'état initial d'un 25 exemplaire exécutable du programme; * marquage de cet état comme "non encore exploré" * tant qu'il existe un ou plusieurs états abstraits non-terminaux marqués "non encore explorés": choix de l'un de ces états; marquage de l'état choisi comme "désormais exploré"; exécution abstraite du programme à partir de cet état en prenant en compte toutes ses interactions possibles (événements et commandes reçus, etc), ce qui conduit à un ou plusieurs nouveaux états; marquage de ces nouveaux états comme "non encore explorés" fusion des états de programmes résultants qui sont similaires, en les généralisant si nécessaire. L'arrêt de l'algorithme avec certitude pourra être mis en oeuvre de la manière 10 suivante: * modélisation de l'état d'un programme de manière à ce qu'il n'existe qu'un nombre fini de configurations différentes, ou * généralisation plus ou moins effective des états résultants pour borner 15 le nombre d'états à considérer, l'état quelconque généralisant tous les autres et garantissant ainsi que la fin du processus puisse toujours être forcée. Ce procédé permet de construire un graphe orienté qui modélise les transitions 20 d'état du programme Les sommets (ou noeuds) de ce graphe sont constitués par les différents états rencontrés; les arêtes (ou arcs) de ce graphe représentent les calculs et interactions effectuées par le programme, et les portions de programme exécutées correspondantes. Les fragments de programme déterminés comme supprimables sont ceux qui ne sont plus exécutables une fois que le programme a atteint un certain état. Autrement dit, s'il existe un sommet S du graphe à partir duquel certaines arêtes ne sont pas accessibles, alors les régions de programme correspondant à ces arêtes inaccessibles et ne figurant pas parmi les régions correspondant aux 30 arêtes accessibles depuis S sont supprimables lorsque l'exécution du programme atteint un état correspondant à S Les fragments ainsi identifiés sont supprimables sans affecter la sémantique du programme, sous l'hypothèse que le programme en est à sa dernière exécution. La quantité et la taille des fragments de programme supprimables déterminés par ce procédé dépendent de plusieurs paramètres, notamment: * le degré de précision avec lequel les états du programme sont modélisés, * le degré de précision avec lequel les interactions avec le programme 10 sont modélisées, * la création éventuelle d'états intermédiaires entre chaque interaction avec le programme, * les conditions d'emploi de la généralisation d'état pour éventuellement forcer la terminaison de l'algorithme. Pour des raisons pratiques de ressources mémoire, ce procédé de détermination sera généralement mis en oeuvre en dehors du système d'exécution du programme, avant son chargement Rien n'interdit toutefois qu'il puisse avoir lieu sur le système même. 20 Deuxièmement, l'instrumentation du programme pour marquer les fragments supprimables, ainsi que les conditions sous lesquelles ils peuvent être supprimés, s'effectue de la manière suivante: Les fragments doivent tout d'abord être marqués afin d'être connus du système Ce marquage permet d'une part de structurer le programme en mémoire afin de favoriser la suppression de code, par exemple avec une préfragmentation, et d'autre part de désigner les fragments à supprimer à un moment donné de l'exécution. Le marquage des zones de code supprimables peut s'effectuer de multiples manières Un fragment constitué d'une suite continue d'instructions d'une routine peut par exemple être repéré par une adresse de début et une adresse de fin de fragment, ou bien une adresse de début ou de fin et une longueur de 5 fragment Un fragment peut être également repéré par des marques spéciales, neutres pour l'exécution, pour indiquer l'emplacement du début et de la fin d'un fragment Un fragment constitué d'une routine peut par exemple être repéré par le nom de la routine ou son adresse mémoire. La condition de suppression de code associée à un fragment de programme doit également être conservée Elle peut être arbitrairement complexe. La condition de suppression peut être basée sur le contrôle courant du programme Ce peut être par exemple l'adresse d'un point de programme: 15 lorsque ce point d'exécution est atteint, alors le fragment associé peut être supprimé Ce peut être aussi la désignation d'une routine du programme: lorsque cette routine est appelée, ou lorsqu'elle retourne, alors le fragment associé peut être supprimé. La condition de suppression peut aussi être basée sur les données courantes manipulées par le programme Ce peut être par exemple la désignation d'une variable du programme qui, lorsqu'elle prend une certaine valeur, ou dépasse un certain seuil, signale que le fragment associé peut être supprimé. L'indication des fragments à supprimer peut également être présente dans le code exécutable même. Dans ce cas, le programme signale lui-même au système, au cours de son exécution, qu'un fragment donné peut être supprimé Ce type de mise en 30 oeuvre est particulièrement bien adapté au cas de conditions de suppression complexes car on dispose alors de toute la puissance d'expression d'un programme pour prendre une décision de suppression. Dans le cas d'un système "Java Card", l'information complémentaire 5 concernant les fragments supprimables d'un code exécutable (code rangé dans le "Method Component") peut être intégrée de manière portable au programme objet ("CAP file") sous forme de composants de programmes auxiliaires ("Custom Components"): ces composants seront ignorés par les systèmes qui ne savent pas gérer le compactage par suppression de code. 10 Troisièmement, la transformation éventuelle du programme pour augmenter l'économie mémoire apportée par la suppression de code, s'effectue de la manière suivante: La détermination de fragments de programme supprimables peut être automatique ou non, effectuée sur la plate-forme même d'exécution du programme ou bien à l'extérieur Suite à cette détermination, et à l'instrumentation correspondante, le programme peut optionnellement être automatiquement transformé, sans changer sa sémantique, afin d'optimiser la 20 possibilité de réutilisation des zones mémoire libérées Ce procédé d'optimisation est basé sur plusieurs sortes de transformations de programme, sources de gains divers. Des fragments supprimables initialement séparés dans le corps du programme 25 peuvent être déplacés pour devenir contigus Cette transformation de programme réduit la fragmentation des programmes o l'on a supprimé du code: la taille totale des fragments supprimables est augmentée et le nombre de ces fragments est réduit La possibilité de réutilisation des zones mémoires libérées est donc meilleure Cette transformation est particulièrement utile 30 pour les systèmes de gestion mémoire qui ne disposent pas de mécanisme de défragmentation. Des fragments supprimables peuvent aussi être placés dans des routines spécifiques Comme indiqué précédemment en ce qui concerne la structuration d'un programme en mémoire (pour la défragmentation), cette transformation 5 facilite le mécanisme de suppression de code Elle ne nécessite même aucun mécanisme si la dernière routine du bloc mémoire contient le programme. Des fragments supprimables peuvent être également regroupés à la fin du programme, dans l'ordre inverse de suppression probable Autrement dit, le 10 fragment qui a le plus de chance d'être supprimé est placé tout à la fin du bloc programme Le fragment suivant qui a le plus de chance d'être supprimé est placé juste avant, et ainsi de suite Cette transformation facilite la suppression de code par réduction dynamique de taille de blocs Par exemple, dans le cas de "Java Card", on pourra placer la méthode "install" à la fin du "Method 15 Component", précédée de la méthode "process Data". Dans le cas général, il n'existe pas d'ordre optimal pour l'ordonnancement des fragments supprimables car les choix de suppression peuvent dépendre de données dynamiques: il n'existe pas de tri meilleur que les autres Dans le cas 20 o les fragments supprimables sont déterminés par traitement automatique de programme, comme décrit ci- dessus, un ordre convenable est fourni par un parcours en profondeur d'abord du graphe d'état, en partant de l'état initial, et une sélection des fragments supprimables rencontrés lors de ce parcours. Certains fragments qui sont supprimables en fonction de données dynamiques 25 (donc inconnues au moment de l'ordonnancement) peuvent être omis de la suppression pour aménager une chaîne continue de fragments dont la suppression successive est certaine. Ces transformations peuvent nécessiter l'introduction de sauts ou d'appels de 30 routine Dans la mesure o ces transformations de programme déplacent du code, elles peuvent aussi nécessiter le relogeage des zones de programme affectées par les mouvements de code. Ces transformations peuvent être automatisées ou bien manuelles, c'est-àdire 5 laissées à l'appréciation de la personne qui prépare le programme pour le compactage par suppression de code. Il faut noter que ces transformations ne sont pas exclusives les unes des autres; elles peuvent être combinées. Concernant la décision de suppression de fragments de programme, trois entités peuvent décider de supprimer un fragment de code: le programme, le système et l'administrateur du système. Le programme peut être instrumenté, manuellement ou automatiquement, pour signaler au système qu'un de ses fragments peut être supprimé C'est l'exécution même du programme qui déclenche alors la suppression Signaler qu'un fragment est supprimable peut être mis en oeuvre de diverses manières: instruction ou groupe d'instructions spécialisé, appel à une routine spécifique 20 du système, etc La spécification du fragment supprimable peut être mis en oeuvre de diverses manières: désignation d'une ou plusieurs zones de code, d'une routine ou d'un groupe de routines particulières, de la routine courante, etc Par exemple, en "Java Card", la méthode "install" pourrait être terminée par l'appel à une méthode du système qui signalerait que la méthode en cours 25 d'exécution n'est plus utile et peut être supprimée. Le système, s'il dispose d'informations concernant la suppression possible de fragments de programme au cours de l'exécution (que ces fragments et conditions de suppression aient été déterminés automatiquement ou non), peut 30 prendre l'initiative de supprimer certains de ces fragments dès lors que les conditions correspondantes sont remplies. La personne qui gère le système peut également forcer la suppression de certains fragments de programme Dans ce cas de figure, le système doit disposer d'une commande qui permet de stipuler des fragments de programme à supprimer. Ces trois sources de choix ne sont pas exclusives les unes des autres; elles peuvent être combinées. Quatrièmement, la structuration en mémoire d'un programme avec fragments supprimables et la suppression effective de ces fragments pour permettre la réutilisation des zones mémoire libérées correspondantes s'effectue de la manière suivante: Une fois prise la décision de supprimer certains fragments, la libération des zones mémoire correspondantes ne devient effective qu'en fonction de la structuration réelle du programme en mémoire Cela se résume aux cas suivants: * si le programme est statiquement préfragmenté, chaque fragment à supprimer est libéré individuellement, auprès du gestionnaire mémoire du système. * si le gestionnaire mémoire du système permet une fragmentation dynamique, le programme est fragmenté au vol et les fragments à 25 supprimer sont libérés individuellement, comme dans le cas précédent. * si les fragments à supprimer sont localisés en fin de blocs mémoire, l'espace mémoire correspondant est libéré en redimensionnant les blocs pour en réduire la taille. * si le système est muni d'un mécanisme pour reloger du code, tous les 30 éléments non supprimés du programme sont rassemblés en début de bloc, relogés, et le bloc est redimensionné pour en réduire la taille. Ces différents types de suppression effective ne sont pas exclusifs; ils peuvent être combinés. Si un fragment de code peut être supprimé sans que la sémantique du programme soit préservée (le programme perd alors certaines de ses fonctionnalités), il est recommandé de mettre en place un mécanisme de contrôle Une erreur sera ainsi notifiée si l'exécution du programme nécessite un fragment supprimé Pour ce faire, on peut par exemple remplacer le code 10 supprimé par du code qui lève une erreur. Si un fragment supprimé doit être remplacé par du code qui signale une erreur, un nouveau bloc mémoire peut être alloué à cet effet Alternativement, le bloc supprimé peut aussi être réutilisé en le redimensionnant pour l'adapter à la 15 taille du code qui signale l'erreur. Ainsi le procédé proposé selon l'invention est particulièrement adapté à la libération de ressources mémoire sur des plates-formes telles que des petits systèmes embarqués et par conséquent autorise la réutilisation de ces dites 20 ressources mémoire. REVENDICATIONS 1 Procédé de compactage de programme par suppression dynamique de code, caractérisé en ce qu'il comprend les étapes suivantes: * la détermination de fragments d'un programme qui peuvent être supprimés soit sans en modifier la sémantique lorsque le programme en est à sa dernière exécution soit en modifiant la sémantique lorsque ces modifications sont acceptables, * l'instrumentation d'un programme pour marquer des fragments supprimables et les conditions sous lesquelles ils peuvent être supprimés, * la structuration en mémoire d'un programme avec fragments supprimables et la suppression effective de ces fragments pour 15 permettre la réutilisation des zones mémoire libérées correspondantes. 2 Procédé selon la revendication 1, caractérisé en ce qu'avant la susdite structuration en mémoire d'un programme, le procédé comprend la transformation du programme pour 20 augmenter l'économie mémoire qu'apportera la suppression de programmes supprimables. 3 Procédé selon la revendication 1, caractérisé en ce que la susdite détermination de fragments de programmes 25 supprimables s'effectue automatiquement par analyse statique de programme. 4 Procédé selon la revendication 3, caractérisé en ce que la susdite détermination de fragments de programmes supprimables s'effectue à partir d'un graphe orienté construit selon la séquence 30 opératoire suivante: * modélisation, sous forme d'un état abstrait, de l'état initial d'un exemplaire exécutable du programme; * marquage de cet état comme "non encore exploré" * tant qu'il existe un ou plusieurs états abstraits non-terminaux marqués comme "non encore explorés" choix de l'un de ces états; marquage de l'état choisi comme "désormais exploré"; exécution abstraite du programme à partir de cet état en prenant en compte toutes ses interactions possibles et produisant un ou 10 plusieurs nouveaux états; marquage de ces nouveaux états comme "non enclore explorés" fusion des états de programmes résultants qui sont similaires, en les généralisant si nécessaire; les noeuds du graphe étant constitués par les différents états rencontrés dans la 15 susdite séquence opératoire, les arcs entre deux états de ce graphe représentant les portions de programme exécutées pour passer d'un état à l'autre dans la susdite séquence opératoire, et les fragments supprimables étant les portions de programme correspondant aux arcs qui ne sont plus accessibles à partir d'un certain noeud sous la condition que l'exécution conduit à l'état représenté par 20 ce noeud. Procédé selon la revendication 4, caractérisé en ce que l'arrêt de la susdite séquence avec certitude est mis en oeuvre selon au moins l'un des deux processus suivants: * la modélisation de l'état d'un programme de manière à ce qu'il n'existe qu'un nombre fini de configurations différentes, * la généralisation des états résultants pour borner le nombre d'états à considérer, l'état quelconque généralisant tous les autres et garantissant ainsi que la fin du processus puisse toujours être forcée. 6 Procédé selon la revendication 4, caractérisé en ce qu'il comprend une détermination des fragments de programme supprimables qui s'effectue en fonction d'un ou plusieurs des paramètres suivants: * le degré de précision avec lequel les états du programme sont modélisés, * le degré de précision avec lequel les interactions avec le programme sont modélisées, * la possibilité de création d'états intermédiaires entre chaque interaction 10 avec le programme, * les conditions d'emploi de la généralisation d'état pour forcer la terminaison de l'algorithme. 7 Procédé selon la revendication 1, caractérisé en ce que l'instrumentation du programme consiste en une ou plusieurs des informations suivantes: * des données auxiliaires n'altérant pas l'exécution du programme et destinées à être exploitées par le système d'exécution, * des instructions supplémentaires incluses dans le corps du programme et 20 destinées à être exécutées au même titre que les instructions ordinaires du programme. 8 Procédé selon la revendication 1, caractérisé en ce qu'il comprend un marquage des fragments supprimables 25 effectué de la manière suivante: * le repérage d'une adresse de début et d'une adresse de fin du fragment, et/ou * le repérage d'une adresse de début ou de fin et de la longueur du fragment, et/ou * le repérage d'un identifiant de routine, et/ou * l'introduction de marques spéciales, neutres pour l'exécution, pour indiquer l'emplacement du début et de la fin d'un fragment. 9 Procédé selon la revendication 1, caractérisé en ce que les conditions de suppression sont basées sur: * le contrôle courant du programme, et/ou * les données courantes manipulées par le programme. Procédé selon la revendication 1, caractérisé en ce que la transformation du programme pour augmenter l'économie mémoire apportée par la suppression de code s'effectue selon au moins l'une des trois possibilités suivantes: * le déplacement des fragments supprimables initialement séparés dans le corps du programme, pour devenir contigus, * le positionnement des fragments supprimables dans des routines spécifiques, * le regroupement des fragments supprimables en fin de bloc de programme dans l'ordre inverse de suppression probable. 11 Procédé selon l'une des revendications 4 et 10, caractérisé en ce que, dans le cas o les fragments supprimables sont déterminés par analyse statique de programme, un ordre de suppression convenable est fourni par un parcours en profondeur d'abord du graphe d'état, en partant de l'état initial, et une sélection des fragments supprimables 25 rencontrés lors de ce parcours. 12 Procédé selon la revendication 10, caractérisé en ce que certains fragments qui sont supprimables en fonction des données dynamiques, peuvent être omis de la suppression pour aménager une 30 chaîne continue de fragments dont la suppression successive est certaine. 13 Procédé selon la revendication 1, caractérisé en ce que la structuration en mémoire d'un programme avec fragments supprimables et la suppression effective de ces fragments pour permettre la réutilisation des zones mémoire libérées correspondantes s'effectuent selon au moins l'un des quatre types de suppression suivants: * si le programme est statiquement préfragmenté, chaque fragment à supprimer est libéré individuellement, auprès du gestionnaire mémoire du système, * si le gestionnaire mémoire du système permet une fragmentation 10 dynamique, le programme est fragmenté au vol et les fragments à supprimer sont libérés individuellement, comme dans le cas précédent, * si les fragments à supprimer sont localisés en fin de blocs mémoire, l'espace mémoire correspondant est libéré en redimensionnant les blocs pour en réduire la taille, * si le système est muni d'un mécanisme pour reloger du code, tous les éléments, non supprimés du programme, sont rassemblés en début de bloc, relogés, et le bloc est redimensionné pour en réduire la taille. 14 Procédé selon la revendication 1 destiné à être implémenté sur des 20 systèmes embarqués, caractérisé en ce qu'un programme à fragments supprimables s'exécutant sur ces susdits systèmes est structuré en mémoire selon les informations mises à disposition par l'instrumentation de ce programme, et en ce que des fragments supprimables sont effectivement supprimés lorsque les conditions stipulées par 25 l'instrumentation du programme sont remplies.