Brevet FR2961922A1 — publié le 20111230

Procédé de compilation sélective, dispositif et produit programme d'ordinateur correspondant. 1 DOMAINE DE L'INVENTION La présente invention se rapporte au domaine de la compilation de 5 programmes ou d'applications logicielles. La présente invention se rapporte plus particulièrement à la compilation de programmes ou d'applications logicielles dans des environnements hétérogènes. Un programme informatique, ou une application logicielle se compose en règle générale d'un ensemble d'instructions binaires ou intermédiaires dites 10 exécutables. Ces instructions exécutables sont usuellement issues d'une compilation d'un programme écrit dans un langage source. Ainsi, pour pouvoir créer une application logicielle, un développeur rédige un programme source écrit dans un langage de programmation spécifique. Ce programme source est ensuite compilé afin de former un programme exécutable. Au cours de cette compilation, 15 les instructions écrites en langage source sont transformées en programme binaire qui est lui-même exécuté sur une plateforme matérielle telle qu'un ordinateur, un terminal de communication. Pour compiler un programme écrit dans un langage source pour une certaine cible (processeur, plateforme, ...), il y a quatre méthodes générales : 20 - disposer d'un compilateur complet, c'est-à-dire comprenant une partie qui se charge de reconnaître le langage source, et une autre qui se charge de créer le code pour la cible choisie ; - disposer d'un compilateur du langage source vers un code intermédiaire, et fournir une machine virtuelle de ce code intermédiaire sur la cible choisie. 25 C'est le cas pour le langage JavaTM par exemple ; - fournir, à un compilateur qui existe déjà pour la cible choisie, un module complémentaire pour reconnaître le langage source ; - disposer d'un compilateur qui transforme un programme écrit dans un langage source en un programme écrit dans un langage intermédiaire, et 30 mettre en oeuvre un compilateur existant du langage intermédiaire pour la cible choisie. 2 SOLUTIONS DE L'ART ANTERIEUR Considérant le cas où l'application est compilée du langage source vers un code intermédiaire, et que ce code intermédiaire est exécuté par une machine virtuelle sur la cible choisie, comme c'est le cas général pour le langage JavaTM, il se pose le problème de la performance d'exécution de l'application. La Figure 1 décrit le principe général d'une technique d'exécution de code à base de machine virtuelle. Le code source 100 est compilé vers un code intermédiaire 102 grâce au compilateur 101. Puis ce code est exécuté sur une machine virtuelle 103, elle- même s'exécutant sur le système d'exploitation 104, lui-même s'exécutant sur une plateforme matérielle 105. Dans la mesure où le code intermédiaire doit pouvoir s'exécuter sur n'importe quelle plateforme disposant d'une machine virtuelle adaptée au code intermédiaire, celui-ci n'est pas optimisé. Dans un contexte d'optimisation de la performance du code intermédiaire, on distingue deux techniques d'optimisation générales dans l'état de l'art. La première technique consiste à réaliser une compilation du code intermédiaire de façon dynamique. On la désigne par compilation dynamique. Pour se faire la machine virtuelle comprend un compilateur capable de compiler dynamiquement des portions de code intermédiaires en binaire, et comprend également un mécanisme pour exécuter dynamiquement le code binaire généré par ce compilateur à la place du code intermédiaire original. Ainsi l'exécution de l'application est constituée d'un mixte de code intermédiaire et de code binaire généré dynamiquement. On distingue deux grands types de réalisations de la compilation dynamique : le « just in time » (JIT) et le « dynamic adaptive compiler » (DAC). Le Just In Time a généralement une granularité de compilation à la méthode (il ne peut compiler que des méthodes entières). Il réalise la compilation en code binaire de la méthode à exécuter lors de la première exécution de la méthode. Le dynamic adaptive compiler (DAC) met en oeuvre une autre stratégie. Il exécute l'application par la machine virtuelle et détermine dynamiquement les parties de code pénalisant la performance de l'application. Ces parties sont appelées les points chauds de l'application. Chaque DAC a sa propre stratégie de détection de point chaud. Par exemple, les méthodes les plus souvent exécutées, ou les méthodes comprenant des boucles, ou des méthodes prenant le plus de temps à s'exécuter. Une fois cette identification faite, il compile les points chauds en code binaire. Ensuite, la machine virtuelle exécute le code binaire des points chauds. On présente, en relation avec la figure 2, le principe général de la compilation et de l'exécution d'une application grâce à une machine virtuelle, en combinant un compilateur dynamique afin d'accélérer l'exécution de l'application. Une application logicielle source (100) est rédigée par un développeur d'application. Ce programme source comprend des instructions de programme informatique écrites dans un langage de programmation source. Le programme source (100) subit une première phase de compilation par un compilateur (101) qui aboutie à sa transformation en un programme intermédiaire (102). Ce programme intermédiaire (102) est exécuté par une machine virtuelle (103) qui s'exécute au-dessus d'un système d'exploitation (104) en binaire, qui repose sur une plateforme matérielle (105). Cette machine virtuelle (103) est couplée à un compilateur dynamique (106) qui détermine automatiquement et compile de façon dynamique des portions de code intermédiaire en code binaire au sein d'un emplacement de mémoire temporaire (buffer) de code binaire (107). La machine virtuelle (103) comprend également des moyens d'exécution d'une version binaire d'un code intermédiaire, si il existe, afin d'accroître la performance de l'application. L'utilisation d'un compilateur dynamique pose cependant deux problèmes. Tout d'abord un compilateur dynamique prend du temps pour s'exécuter en plus de l'application à la fois pour déterminer les points chauds, et lors de la compilation du code intermédiaire en code binaire. En effet, pour réaliser l'identification des points chauds, une instrumentation de l'interpréteur de la machine virtuelle est généralement réalisée afin de surveiller le comportement de l'application. Ces instrumentations pénalisent de ce fait la performance de l'application. Concernant le compilateur, afin de limiter leur temps de compilation, les optimisations réalisées par ces compilateurs sont simples et ne peuvent pas être agressives. Ceci va limiter la performance du code binaire généré par rapport à un compilateur qui s'exécute en amont de l'exécution. Ensuite, ces solutions utilisent de la mémoire temporaire pour stocker les codes binaires générés. Dans la majorité des cas, ce code est stocké dans une zone de mémoire limitée, et le compilateur doit donc faire de façon continue des choix pour déterminer quels sont les bons codes binaires à garder dans ce buffer. I1 en découle un problème de performance de ces compilateurs dynamiques dès lors qu'ils gèrent de nombreuses applications, ou que la taille de cette zone mémoire est petite. Ainsi les compilateurs dynamiques, bien que générant du code binaire ne permettent pas d'atteindre des niveaux de performances importants. Par ailleurs, plus le code intermédiaire est important (comme c'est le cas sur une plateforme AndroidTM où les applications, services systèmes et les interfaces de programmation sont exécutées en code intermédiaire) plus la détection de point chaud est difficile à réaliser, et plus la gestion de buffer de code est sollicitée, ce qui limite d'autant la performance du système. La deuxième technique d'optimisation de la performance du code intermédiaire consiste à rendre la machine virtuelle plus rapide sur la cible choisie. Cette optimisation peut se faire en optimisant la machine virtuelle pour qu'elle exploite le plus possible les capacités du processeur qui l'utilise. Elle peut également se faire au travers de support matériel spécifique additionnel. Elle peut également être réalisée par la conception d'algorithme spécifique permettant d'accroître la performance de la machine virtuelle sur la cible. En dehors de ces deux solutions, il demeure la possibilité d'utiliser un compilateur hors ligne qui compile la totalité du code source ou le code intermédiaire en code binaire en amont de l'exécution de l'application. Cette approche permet de ne pas pénaliser l'exécution de l'application par le temps pris par le compilateur dynamique, et permet également de réaliser des compilations très optimisées de l'application. Cette solution a l'avantage de permettre d'obtenir des performances importantes pour les applications. Cette solution impose cependant de compiler complètement une application et utilise le système d'exploitation pour contrôler l'exécution de l'application. Dans les environnements où la machine virtuelle est le coeur d'exécution du système, comme c'est le cas pour le système AndroidTM, cela la rend inutilisable car cette solution n'est pas prévue pour s'intégrer à une machine virtuelle. Par ailleurs, la taille du code binaire généré étant plus important que la taille du code interprété, la taille de l'application devient très importante et implique l'utilisation de plus de mémoire. 3 RESUME DE L'INVENTION L'invention ne comprend pas ces inconvénients de l'art antérieur. En effet, l'invention concerne un procédé de compilation d'une application logicielle destinée à s'exécuter au sein d'une machine virtuelle d'une plateforme matérielle, ladite application logicielle se présentant originellement sous la forme d'un ensemble de codes à compiler. Selon l'invention un tel procédé comprend une phase de compilation sélective dudit ensemble de codes à compiler délivrant une application compilée comprenant une première partie applicative exécutée par ladite machine virtuelle en utilisant des instructions de ladite machine virtuelle et une deuxième partie applicative comprenant des instructions binaires directement exécutable sur ladite plateforme matérielle. Ainsi l'invention permet d'optimiser la performance des applications en réalisant, à partir d'un même ensemble de codes une application constituée d'une partie applicative exécutée par ladite machine virtuelle et une partie applicative exécutée directement par la plateforme matérielle, sans utilisation de l'interpréteur de la machine virtuelle. L'ensemble de codes à compiler est constitué de fichiers qui sont écrits dans un unique langage. Selon un mode de réalisation particulier, ledit ensemble de codes à compiler est un ensemble de codes intermédiaires et en ce que ledit procédé comprend une première phase de compilation d'un ensemble de codes sources et délivrant ledit ensemble de codes intermédiaires utilisés lors de ladite phase de compilation sélective. Ainsi, l'invention permet d'optimiser directement un code intermédiaire, qui a déjà fait l'objet d'une première compilation, pour optimiser l'exécution de ce code intermédiaire. Selon un mode de réalisation particulier, ledit ensemble de codes à 10 compiler est un ensemble de codes sources écrits dans un langage de programmation. Selon une caractéristique particulière ladite phase de compilation sélective comprend : - une première étape de sélection, parmi ledit ensemble de code à compiler, 15 d'un premier sous ensemble de code à compiler ; - une étape de compilation dudit premier sous ensemble de code à compiler délivrant ladite première partie applicative. Selon une caractéristique particulière, ladite phase de compilation sélective comprend en outre : 20 - une deuxième étape de sélection, parmi ledit ensemble de code à compiler, d'un deuxième sous ensemble de code à compiler complémentaire dudit premier sous ensemble préalablement sélectionné ; - une étape de compilation dudit deuxième sous ensemble de code à compiler délivrant un troisième sous ensemble de code source à compiler ; 25 - une étape de compilation dudit troisième sous ensemble de code source à compiler délivrant ladite deuxième partie applicative. Selon une caractéristique particulière, ledit procédé comprend en outre lors de ladite étape de compilation dudit deuxième sous ensemble de code source à compiler, une étape d'introduction d'au moins une structure d'interfaçage de 30 ladite deuxième partie applicative avec ladite machine virtuelle. Cette structure de données peut par exemple une interface de type JNI (« Java Native Interface ») Selon une caractéristique particulière, ledit ensemble de codes à compiler est un ensemble de « ByteCode » Java. Selon une caractéristique particulière, ledit ensemble de codes à compiler est un ensemble de « ByteCode » Dalvik. Selon une caractéristique particulière, ledit ensemble de codes à compiler est un ensemble de codes Java. Selon un mode de réalisation particulier, ledit procédé est mis en oeuvre 10 préalablement à une exécution de ladite application logicielle au sein de ladite machine virtuelle. Selon un autre aspect, l'invention concerne également un dispositif de compilation d'une application logicielle destinée à s'exécuter au sein d'une machine virtuelle d'une plateforme matérielle, ladite application logicielle se 15 présentant originellement sous la forme d'un ensemble de codes à compiler. Selon l'invention un tel dispositif comprend des moyens de compilation sélectifs dudit ensemble de codes à compiler délivrant une application compilée comprenant une première partie applicative exécutée par ladite machine virtuelle en utilisant des instructions de ladite machine virtuelle et une deuxième partie applicative 20 comprenant des instructions binaires directement exécutable sur ladite plateforme matérielle. Selon un autre aspect, l'invention concerne également un programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre du procédé de navigation tel que décrit précédemment, lorsque ce 25 programme est exécuté par un processeur. L'invention apporte une solution nouvelle et inventive à ces problèmes de l'art antérieur. En effet l'invention propose un procédé de compilation automatique et sélectif d'un code écrit dans un langage de programmation source ou intermédiaire afin de générer un code binaire des parties sélectionnées pouvant 30 être exécuté par une machine virtuelle. Cette machine virtuelle pouvant de façon complémentaire exécuter un compilateur dynamique qui se chargera de compiler le code intermédiaire restant à s' exécuter. Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive de la compilation d'applications logicielles pour les environnements fonctionnant à base de machine virtuelle. En étant partiel et sélectif, l'invention permet au développeur de choisir précisément ce qu'il veut compiler afin de garder le contrôle de l'utilisation de la compilation hors ligne. Elle permet également de combiner les approches de compilation hors ligne et l'approche de compilation dynamique, dans l'objectif de fournir une meilleure performance d'exécution 4 LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : - la figure 1, déjà commentée, présente le principe général de la compilation d'un code vers un code intermédiaire afin de l'exécuter dans une machine virtuelle ; - La figure 2, déjà commentée, présente le principe général de la compilation dynamique d'une application logicielle qui s'exécute dans une machine virtuelle ; - la figure 3 décrit le principe de l'invention ; - la figure 4 est un schéma de principe d'un dispositif de compilation selon l'invention. 5 DESCRIPTION DETAILLEE DE L'INVENTION 5.1 Rappel du principe de l'invention Le principe général de l'invention réside dans la combinaison d'une approche statique de la compilation, permettant de créer des applications informatiques optimisées en réalisant une compilation (préalablement à l'exécution de l'application) tout en conservant une exécution basée sur l'implémentation de machines virtuelles. Comme cela a déjà été mentionné, une des problématiques des applications qui fonctionnent à l'aide de machines virtuelles est la performance. En effet, le principe à la base de l'utilisation de machines virtuelles est de permettre une portabilité du code intermédiaire (issu d'une ou plusieurs compilations de code source) sur toute plateforme matérielle disposant d'une machine virtuelle capable d'exécuter le code intermédiaire en question. Or cette universalité du code intermédiaire implique de réaliser une interprétation du code intermédiaire à l'aide d'instructions comprises par le processeur, rendant peut performant l'exécution de ce code. Aussi, cela est généralement reconnu, le code binaire offre des performances nettement supérieures à un code intermédiaire. Cette performance provenant principalement du fait que le code binaire s'exécute directement par le processeur de la plateforme matérielle en utilisant l'ensemble des instructions du processeur et sans nécessité d'interprétation complémentaire. L'invention se rapporte ainsi à une technique de compilation pour les environnements d'exécution à base de machine virtuelle qui fournit une meilleure performance d'exécution. Le principe d'amélioration des performances repose sur le déplacement de l'exécution de certaines parties de code intermédiaire sous la forme de code binaire nettement plus performant, tout en restant sous le contrôle d'exécution de l'application par la machine virtuelle cible. La compilation se base sur le code source (ou intermédiaire) de l'application. Lors de la compilation, le compilateur réalise une génération de code comprenant deux parties : un premier ensemble de code intermédiaire qui s'exécute en mettant en oeuvre la machine virtuelle et un deuxième ensemble de code binaire qui s'exécute directement par le processeur de la plateforme matérielle. La Figure 3 décrit le principe de l'invention. L'invention permet au développeur de sélectionner (101) depuis un code source ou un code intermédiaire 100 les parties de codes à compiler en code binaire. Le compilateur 102 génère les codes (103, 104, 106 et 107) permettant d'exécuter les portions de codes choisies par le développeur en code binaire. Les codes générés (103, 104, 106 et 107) vont s'exécuter par la machine virtuelle 105, grâce à son support d'exécution de code binaire 116. La machine virtuelle s'exécute au-dessus du système d'exploitation 108, lui-même s'exécutant sur une plate-forme matérielle 109. Ainsi, l'invention permet au développeur de choisir les morceaux de codes 10 sources devant s'exécuter avec une grande performance, sans opération d'intégration manuelle additionnelle. La sélection du code source (et/ou intermédiaire) à compiler en binaire : - Est faite en fonction des choix du développeur. Il n'y a donc plus de détection de points chauds par la machine virtuelle pour ce code 15 source sélectionné - Cette sélection permet de travailler le compromis expansion mémoire généré et donc d'optimiser la taille mémoire nécessaire. Ceci est particulièrement intéressant en fonction des types de machines virtuelles utilisés, comme cela sera décrit par la suite. 20 - Permet d'accélérer des codes d'application, ou de services systèmes, - Permet d'accélérer des libraires de la machine virtuelle. Au niveau de l'intégration basée sur le support de l'exécution de code binaire de la machine virtuelle : 25 - L'intégration à la machine virtuelle est transparente. Il n'y a pas de modification de la machine virtuelle. - La performance du code final dépend du support d'exécution de code binaire de la machine virtuelle. - L'intégration est compatible avec une solution de compilation dynamique d'une machine virtuelle. Cette intégration permet de cumuler les performances. - Le code binaire permet d'être chargé dynamiquement, ou embarqué selon possibilités de la machine virtuelle. - Ce type d'intégration offre la possibilité de procéder par compilation successive pour arriver au résultat (optimiseur de code intermédiaire, compilateur binaire dédié). L'invention permet également de disposer de différentes granularités de compilation : méthode, application, service, APIS, ou bout de code. Le fait de disposer de différentes granularités de compilation permet de cibler précisément les parties de code à accélérer selon les cas. La méthode de compilation de l'invention est mise en oeuvre en amont de l'exécution de l'application sur la plateforme. N'ayant pas de contraintes de ressources, le compilateur peut ainsi utiliser des optimisations agressives très poussées pour générer le code binaire ou le code intermédiaire qui permettront d'améliorer encore plus les performances de l'application. Il est également possible d'utiliser un schéma de compilations successives afin de générer les codes intermédiaires et binaires amenées à être exécutés. Ainsi le compilateur générera des codes sources qui seront compilés par des compilateurs tiers pour générer ensuite les codes intermédiaires et les codes binaires. De ce fait, les codes générés bénéficieront du cumul des optimisations réalisées par ces compilateurs. Selon un mode de réalisation particulier, afin de permettre son exécution par la machine virtuelle cible, un ensemble de codes spécifiques liant les deux ensembles (intermédiaire et binaire) est intégré aux deux ensembles de codes générés en utilisant une interface native de la machine virtuelle. L'utilisation de cette interface native impacte cependant le degré d'amélioration de performance obtenu. Selon un mode de réalisation particulier, afin de maximiser la performance de l'application le compilateur utilise l'une des interfaces natives disponibles par la machine virtuelle. Ainsi, cette interface native pourra être soit l'interface native standard de la machine virtuelle permettant de faire le lien avec des librairies natives, soit une des interfaces interne plus performante. Ainsi, il n'est pas nécessaire de prévoir un ensemble de codes spécifiques pour lier l'ensemble de code intermédiaire et l'ensemble de code binaire. Selon une caractéristique particulière, la dépendance entre le procédé et la machine virtuelle réside dans l'interface native de cette dernière. Parfois cette interface native n'a pas besoin d'être modifiée, parfois, elle doit être modifiée afin d'obtenir l'amélioration de performance désiré. Dans ce mode de réalisation, comme le procédé de compilation s'appuie sur l'une des interfaces natives de la machine virtuelle, il permet de conserver le système objet de la machine virtuelle cible, sans avoir à le modifier. Néanmoins, l'utilisation d'un second système objet permettant d'exécuter le code binaire sans avoir à utiliser l'interface native de la machine virtuelle est également possible afin d'améliorer toujours plus les performances. A l'extrême, selon un mode de réalisation particulier, la quasi totalité d'une application peut être compilée en code binaire en utilisant un système objet propre. Dans ce mode de réalisation particulier l'ensemble de code intermédiaire généré est minimal et permet à la machine virtuelle de réaliser le minimum d'opération requise pour exécuter l'application telle que lancer, terminer ou suspendre l'exécution de l'application sur le terminal. Cependant, quel que soit le mode de réalisation, le moteur de base de l'exécution de l'application reste la machine virtuelle. La base du procédé consistant à compiler un ensemble de code source ou intermédiaire en deux ensembles de codes (intermédiaire et binaires) est automatique. L'ensemble du procédé peut être complètement automatique, ou comporter des phases manuelles complémentaires. Généralement le code binaire occupe une place plus importante en mémoire que du code intermédiaire. En effet, celui-ci est prévu pour tenir compte des contraintes de taille mémoire du terminal. Ainsi lors de l'utilisation de l'invention, lorsqu'un code intermédiaire est compilé en code binaire, il y a un accroissement de la taille du code de l'application. Afin de contrôler à la fois le compromis entre amélioration de performance et taille du code binaire généré, le procédé permet, dans au moins un mode de réalisation, de sélectionner les parties de codes à compiler. Ainsi le développeur de l'application maîtrise l'expansion de code au vu des contraintes mémoire du terminal cible. Dans un mode de réalisation alternatif, le compilateur peut également décider lui-même de la découpe des codes à effectuer en utilisant une optimisation particulière qui permet de réaliser un compromis expansion mémoire/performance de façon automatique. Le procédé est compatible avec une machine virtuelle cible interprétée. Cette machine virtuelle peu également disposer d'un compilateur dynamique qui s e chargera d'améliorer la performance du code intermédiaire. Ainsi, les améliorations de performances se cumulent (initiale avec le procédé de l'invention et dynamique avec le compilateur dynamique). Le procédé n'est pas restreint aux applications et peut être utilisé pour du 20 code source ou intermédiaire d'une application, service ou librairie amené à être exécuté par la machine virtuelle. Selon un mode de réalisation particulier, le procédé peut être utilisé sur tous les ensembles de codes d'une application, ou une portion de code particulier, sans limite de granularité (une classe, une méthode, ou un morceau de code d'une 25 méthode). Par la suite on décrit une mise en oeuvre de l'invention adaptée à la plateforme AndroïdTM. Il est évident que l'invention n'est nullement limitée à cette plateforme particulière mais peut également être mise en oeuvre dans le cadre d'autres plateformes. 5.2 Description d'un mode de réalisation On présente dans ce mode de réalisation, la mise en oeuvre de l'invention pour un environnement d'exécution AndroidTM L'environnement d'exécution AndroidTM de GoogleTM est basé sur une distribution du système d'exploitation LinuxTM auquel sont ajoutées des librairies, une machine virtuelle qui se nomme DalvikTM et du code intermédiaire. Ce code intermédiaire comprend des applications, des services système et des librairies embarqués sur la plateforme. Les codes sources des applications, services et librairies sont écrits en JAVATM, puis compilés en code intermédiaire DalvikTM La particularité d'AndroidTM est qu'il est adapté au fonctionnement de terminaux légers disposant, au regard des ordinateurs personnels actuels, de faibles capacités d'exécution. La machine virtuelle DalvikTM a la particularité d'être basée sur une architecture à « registres » (de l'anglais « register-based virtual machines ») à la différence des autres machines virtuelle qui sont dite «à pile » (de l'anglais « stack based virtual machines »). En général, les machines virtuelles à base de «pile» doivent utiliser les instructions pour charger des données sur la pile et de manipuler les données, et, par conséquent, exigent plus d'instructions que les machines à « registre » pour mettre en oeuvre le code de même niveau, mais les instructions dans une machine à « registre » doivent encoder les registres source et destination et, par conséquent, ont tendance à être plus volumineuses. La chaîne de compilation d'AndroïdTM pour le langage java réalise la compilation du code java en code intermédiaire en utilisant deux compilateurs. Le premier compile le code source java en code intermédiaire Java (ByteCode Java). Le second compile le code intermédiaire java (ByteCode Java) en code intermédiaire Dalvik (fichier .dex). On a donc une chaîne de deux compilations successives pour aboutir à un code exécutable « .dex » sur une plateforme AndroïdTM à partir d'un code source écrit en java. Dans la plateforme AndroidTM, pour améliorer les performances, la mise en oeuvre de l'invention est la suivante : - le code source java initial CSj, est compilé à l'aide du compilateur java de la plateforme AndroidTM afin de produire un premier ensemble de code intermédiaire (ByteCode Java) CIj, qui est, dans ce mode de réalisation, le code à compiler. - puis, le code intermédiaire CIj est compilé de façon sélective pour obtenir deux ensembles de code distincts : un premier ensemble de code source C/C++ CScl et un deuxième ensemble de code intermédiaire CIj2. - plus précisément, le deuxième ensemble de code intermédiaire CIj2 est compilé en code intermédiaire DalvikTM à l'aide du compilateur disponible dans la chaîne de compilation AndroïdTM afin de produire l'application « .dex » exécutable sur la plateforme par l'intermédiaire de la machine virtuelle DalvikTM - le premier ensemble de code source CScl, comprenant du code C/C++ est compilé à l'aide du compilateur C/C++ disponible dans la chaîne de compilation AndroidTM afin d'en générer du code binaire qui se présente sous la forme de librairies dynamiques LinuxTM, afin de produire la deuxième partie de l'application. La machine virtuelle DalvikTM comprend plusieurs interfaces natives, dont une interface JNI. JNI (de l'anglais « Java Native Interface » pour « interface Java Native ») est un framework (« cadre de développement ») qui permet à du Byte Code Java s'exécutant à l'intérieur d'une machine virtuelle java d'appeler (et d'être appelé) par des applications ou librairies dites natives s'exécutant en code binaire. Cette interface JNI est largement utilisée dans les environnements Java. Aussi, afin de lier l'exécution des deux types de codes générés (d'une part le code DalvikTM et d'autre part les librairies dynamiques LinuxTM, le compilateur de l'invention ajoute des codes spécifiques JNI permettant d'exécuter les deux parties. Ainsi, l'invention permet de compiler des parties Java en code natif, tout en gardant des parties de code intermédiaire, le tout en liant l'exécution des deux parties de l'application à l'aide de l'interface JNI de DalvikTM Une autre implémentation de l'invention peut également consister à utiliser l'interface native interne de la machine virtuelle DalvikTM pour éviter l'utilisation de l'interface JNI, qui peut elle-même poser quelques problèmes de performances. Bien entendu, comme cela a déjà été exposé, la machine virtuelle DalvikTM reste maître de l'exécution et son modèle d'exécution objet reste conservé et utilisé pour exécuter l'application. Ce modèle d'exécution objet est en charge de la gestion des champs, des méthodes, de la mémoire associée. D'un point de vue exécution, l'invention permet donc de bénéficier d'un code binaire très performant qui s'exécute au sein de la machine virtuelle. Un autre avantage est de pouvoir tirer parti des propriétés de l'architecture mémoire de la plateforme matérielle. Chaque processeur de la plateforme matérielle possède une architecture mémoire associée. Celle-ci peut être composée de plusieurs niveaux de cache mémoire, de mémoire spécifiques (à accès direct, ROM, ...), de mémoire additionnelle vive ou flash, de différentes fréquences de cadencement. Outre sa performance de base pour exécuter une instruction binaire, la performance du processeur va être fonction de la localisation des instructions et des données d'une application dans sa hiérarchie mémoire. Généralement le processeur permet d'avoir deux canaux d'accès mémoire en parallèle. Un pour les instructions, l'autre pour les données. Ces deux canaux sont par ailleurs optimisés et calibrés en fonction de la distribution des accès instructions et données. Concernant les machines virtuelles, le code intermédiaire est considéré être une donnée. Aussi, tout les accès mémoires passent par le même canal, ce qui pénalise le fonctionnement de l'architecture mémoire et impacte la performance d'exécution. Les compilateurs dynamiques génèrent du code binaire pouvant être chargé par le canal d'instruction. Aussi, ils permettent d'utiliser les deux canaux d'accès mémoire en parallèle. Néanmoins ce code binaire est dans une mémoire vive, empêchant l'utilisation de mémoire morte, résidente à proximité du processeur. Dans une implémentation particulière de l'invention, puisque le compilateur peut s'exécuter en amont de l'intégration du terminal, le code binaire peut être placé dans une mémoire morte proche du processeur. Ceci permet : - de profiter de la performance des mémoires mortes afin de rendre encore plus performant l'application ; - de profiter des performances énergétiques des mémoires mortes permettant d' accroitre l'autonomie de la plateforme ; - de limiter l'utilisation de la mémoire vive en n'y insérant pas de données ou code additionnels. - De profiter de l'utilisation des différents canaux d'accès mémoire instruction et donnée. Au final, la performance globale du système est améliorée. 5.3 Autres caractéristiques optionnelles et avantages Dans au moins un mode de réalisation, l'invention se présente sous la forme d'un dispositif apte à mettre en oeuvre le procédé de compilation tel que décrit précédemment. Un tel dispositif est schématiquement décrit en relation avec la figure 4. Il comprend une mémoire 41, et une unité de traitement 42 qui est équipée d'un microprocesseur piloté par un programme d'ordinateur (ou application). L'unité de traitement 42 reçoit en entrée, via un module d'interface d'entrée I, un ensemble de codes à compiler, que le microprocesseur traite, selon les instructions du programme précité, pour générer une application composée de deux parties. Cette application en deux parties est délivrée par l'intermédiaire de l'interface T. Pour réaliser cette application en deux parties, le dispositif comprend des moyens de compilation sélectifs de l'ensemble de codes à compiler délivrant une application compilée comprenant une première partie applicative exécutée par ladite machine virtuelle en utilisant des instructions de ladite machine virtuelle et une deuxième partie applicative comprenant des instructions binaires directement exécutable sur ladite plateforme matérielle. Les moyens de compilation sélectifs comprennent des moyens de sélection des sous-ensembles de codes à compiler. Ces moyens de sélection sont soit mis en oeuvre de manière manuelle soit mis en oeuvre automatiquement. Une mise en oeuvre automatique de la sélection peut être réalisée par un dispositif de préanalyse de code 43 visant à identifier les portions de code pour lesquelles une optimisation et/ou une exécution binaire est préférable. Les moyens de compilation sélectifs comprennent en outre au moins deux dispositifs de compilation qui permettent d'une part de générer la première partie de l'application, qui est exécutée par la machine virtuelle et la deuxième partie de l'application, qui est exécutée directement par le système d'exploitation de la plateforme matérielle. Ces deux dispositifs de compilation peuvent être complétés par d'autres dispositifs, comme d'autres compilateurs, des éditeurs de liens ou des optimisateurs. REVENDICATIONS1. Procédé de compilation d'une application logicielle destinée à s'exécuter au sein d'une machine virtuelle d'une plateforme matérielle, ladite application logicielle se présentant originellement sous la forme d'un ensemble de codes à compiler caractérisé en ce qu'il comprend une phase de compilation sélective dudit ensemble de codes à compiler délivrant une application compilée comprenant une première partie applicative exécutée par ladite machine virtuelle en utilisant des instructions de ladite machine virtuelle et une deuxième partie applicative comprenant des instructions binaires directement exécutable sur ladite plateforme matérielle. 2. Procédé selon la revendication 1, caractérisé en ce que ledit ensemble de codes à compiler est un ensemble de codes intermédiaires et en ce que ledit procédé comprend une première phase de compilation d'un ensemble de codes sources et délivrant ledit ensemble de codes intermédiaires utilisés lors de ladite phase de compilation sélective. 3. Procédé selon la revendication 1, caractérisé en ce que ledit ensemble de codes à compiler est un ensemble de codes sources écrits dans un langage de programmation. 4. Procédé selon la revendication 1, caractérisé en ce que ladite phase de compilation sélective comprend : - une première étape de sélection, parmi ledit ensemble de code à compiler, d'un premier sous ensemble de code intermédiaire ; - une étape de compilation dudit premier sous ensemble de code à compiler délivrant ladite première partie applicative. 5. Procédé selon la revendication 4, caractérisé en ce que ladite phase decompilation sélective comprend en outre : - une deuxième étape de sélection, parmi ledit ensemble de code à compiler, d'un deuxième sous ensemble de code à compiler complémentaire dudit premier sous ensemble préalablement sélectionné ; - une étape de compilation dudit deuxième sous ensemble de code à compiler délivrant un troisième sous ensemble de code source à compiler ; - une étape de compilation dudit troisième sous ensemble de code source à compiler délivrant ladite deuxième partie applicative. 6. Procédé selon la revendication 5, caractérisé en ce qu'il comprend en outre, lors de ladite étape de compilation dudit deuxième sous ensemble de code source à compiler, une étape d'introduction d'au moins une structure d'interfaçage de ladite deuxième partie applicative avec ladite machine virtuelle. 7. Procédé selon la revendication 1, caractérisé en ce que ledit ensemble de codes à compiler est un ensemble de « ByteCode » Java. 8. Procédé selon la revendication 1, caractérisé en ce que ledit ensemble de codes à compiler est un ensemble de « ByteCode » Dalvik. 9. Procédé selon la revendication 1, caractérisé en ce que ledit ensemble de codes à compiler est un ensemble de codes Java. 10. Procédé selon la revendication 1, caractérisé en ce qu'il est mis en oeuvre préalablement à une exécution de ladite application logicielle au sein de ladite machine virtuelle. 11. Dispositif de compilation d'une application logicielle destinée à s'exécuter au sein d'une machine virtuelle d'une plateforme matérielle, laditeapplication logicielle se présentant originellement sous la forme d'un ensemble de codes à compiler caractérisé en ce qu'il comprend des moyens de compilation sélectifs dudit ensemble de codes à compiler délivrant une application compilée comprenant une première partie applicative exécutée par ladite machine virtuelle en utilisant des instructions de ladite machine virtuelle et une deuxième partie applicative comprenant des instructions binaires directement exécutable sur ladite plateforme matérielle. 12. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution du procédé de compilation selon l'une au moins des revendications 1 à 10, lorsqu'il est exécuté sur un ordinateur.