EP2588953A1 - Procédé de compilation sélective, dispositif et produit programme d'ordinateur correspondant - Google Patents

Procédé de compilation sélective, dispositif et produit programme d'ordinateur correspondant

Info

Publication number
EP2588953A1
EP2588953A1 EP11728266.5A EP11728266A EP2588953A1 EP 2588953 A1 EP2588953 A1 EP 2588953A1 EP 11728266 A EP11728266 A EP 11728266A EP 2588953 A1 EP2588953 A1 EP 2588953A1
Authority
EP
European Patent Office
Prior art keywords
code
compiled
codes
virtual machine
application
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP11728266.5A
Other languages
German (de)
English (en)
Inventor
Gilbert Cabillic
Jean-Philippe Lesot
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Google LLC
Original Assignee
Flexycore SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Flexycore SAS filed Critical Flexycore SAS
Publication of EP2588953A1 publication Critical patent/EP2588953A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/44—Encoding
    • G06F8/443—Optimisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/52—Binary to binary
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G06F9/45516—Runtime code conversion or optimisation

Definitions

  • the present invention relates to the field of compilation of programs or software applications.
  • the present invention relates more particularly to the compilation of programs or software applications in heterogeneous environments.
  • a computer program, or a software application is generally composed of a set of binary or intermediate instructions said executable.
  • These executable instructions are usually derived from a compilation of a program written in a source language.
  • a developer writes a source program written in a specific programming language.
  • This source program is then compiled to form an executable program.
  • the instructions written in source language are transformed into a binary program which is itself executed on a hardware platform such as a computer, a communication terminal.
  • Figure 1 describes the general principle of a virtual machine-based code execution technique.
  • the source code 100 is compiled to an intermediate code 102 by the compiler 101.
  • This code is then executed on a virtual machine 103, itself running on the operating system 104, itself running on a platform 105. Since the intermediate code must be able to run on any platform with a virtual machine adapted to the intermediate code, it is not optimized.
  • the first technique is to compile the intermediate code dynamically. It is referred to as dynamic compilation.
  • the virtual machine includes a compiler capable of dynamically compiling intermediate bits of code into binary, and also includes a mechanism for dynamically executing the binary code generated by this compiler in place of the original intermediate code.
  • the execution of the application consists of a mixture of intermediate code and dynamically generated binary code.
  • JIT just in time
  • DAC dynamic adaptive compiler
  • Just In Time usually has a compilation granularity to the method (it can only compile entire methods). It carries out the compilation in binary code of the method to be executed during the first execution of the method.
  • the dynamic adaptive compiler implements another strategy. It executes the application by the virtual machine and dynamically determines the parts of code penalizing the performance of the application. These parts are called hot spots of the application.
  • Each DAC has its own hotspot detection strategy. For example, the most frequently executed methods, or methods that include loops, or methods that take the most time to execute. Once this identification is made, it compiles hot spots in binary code. Then, the virtual machine executes the binary code of the hotspots.
  • a source software application (100) is written by an application developer.
  • This source program includes computer program instructions written in a source programming language.
  • the source program (100) undergoes a first compilation phase by a compiler (101) which results in its transformation into an intermediate program (102).
  • This intermediate program (102) is executed by a virtual machine (103) that runs over a binary operating system (104), which is based on a hardware platform (105).
  • the virtual machine (103) is coupled to a dynamic compiler (106) that dynamically determines and compiles bit code intermediate code portions within a binary code buffer (107).
  • the virtual machine (103) also includes means for executing a binary version of an intermediate code, if it exists, in order to increase the performance of the application.
  • a dynamic compiler takes time to execute in addition to the application both to determine hotspots, and when compiling the intermediate code in binary code. Indeed, to realize the identification of the hot spots, an instrumentation of the interpreter of the virtual machine is usually performed in order to monitor the behavior of the application. These instrumentations penalize the performance of the application. Concerning the compiler, in order to limit their compilation time, the optimizations realized by these compilers are simple and can not be aggressive. This will limit the performance of the generated binary code compared to a compiler that runs upstream of the execution. Then, these solutions use temporary memory to store the generated binary codes.
  • this code is stored in a limited memory area, and the compiler must therefore make continuous choices to determine which are the correct binary codes to keep in this buffer. This results in a performance problem of these dynamic compilers as they manage many applications, or the size of this memory area is small.
  • the second technique of optimizing the performance of the intermediate code is to make the virtual machine faster on the chosen target. This optimization can be done by optimizing the virtual machine so that it exploits as much as possible the capabilities of the processor that uses it. It can also be done through additional specific hardware support. It can also be achieved by the specific algorithm design to increase the performance of the virtual machine on the target.
  • the invention does not include these disadvantages of the prior art. Indeed, the invention relates to a method of compiling a software application intended to execute within a virtual machine of a hardware platform, said software application originally being in the form of a set of compile.
  • such a method comprises a phase of selective compilation of said set of codes to compile delivering a compiled application comprising a first application part executed by said virtual machine by using instructions from said virtual machine and a second application part comprising binary instructions. directly executable on said hardware platform.
  • the invention makes it possible to optimize the performance of the applications by producing, from a single set of codes, an application consisting of an application part executed by said virtual machine and an application part executed directly by the hardware platform, without using the interpreter of the virtual machine.
  • the set of codes to compile consists of files that are written in a single language.
  • said set of codes to be compiled is a set of intermediate codes and in that said method comprises a first phase of compiling a set of source codes and delivering said set of intermediate codes used during said phase. selective compilation.
  • the invention makes it possible to directly optimize an intermediate code, which has already been the subject of a first compilation, to optimize the execution of this intermediate code.
  • said set of codes to be compiled is a set of source codes written in a programming language.
  • said selective compilation phase comprises:
  • said selective compilation phase furthermore comprises:
  • said method further comprises, during said step of compiling said second subset of source code to be compiled, a step of introducing at least one interfacing structure of said second application part with said virtual machine.
  • This data structure may for example a JNI type interface ("Java Native Interface").
  • this interfacing structure may be a particular structure for making a link with an internal interface, more efficient, of the virtual machine.
  • said set of codes to be compiled is a set of Java "ByteCode”.
  • said set of codes to be compiled is a set of "ByteCode” Dalvik.
  • said set of codes to be compiled is a set of Java codes.
  • said method is implemented prior to an execution of said software application within said virtual machine.
  • the invention also relates to a device for compiling a software application intended to execute within a virtual machine of a hardware platform, said software application originally being in the form of a set of codes to compile.
  • a device for compiling a software application intended to execute within a virtual machine of a hardware platform, said software application originally being in the form of a set of codes to compile.
  • such a device comprises means of selective compilation of said set of codes to compile delivering a compiled application comprising a first application part executed by said virtual machine by using instructions from said virtual machine and a second application part comprising binary instructions. directly executable on said hardware platform.
  • the invention also relates to a computer program comprising program code instructions for implementing the navigation method as described above, when this program is executed by a processor.
  • the invention provides a new and inventive solution to these problems of the prior art. Indeed, the invention proposes a method of automatically and selectively compiling a code written in a source programming language. or intermediate to generate a binary code of the selected parts that can be executed by a virtual machine.
  • This virtual machine can complementarily run a dynamic compiler that will compile the intermediate code remaining to run.
  • the invention is based on a completely new and inventive approach to compiling software applications for virtual machine-based environments.
  • the invention allows the developer to choose precisely what he wants to compile in order to keep control of the use of offline compilation. It also allows to combine the offline compilation approaches and the dynamic compilation approach, with the aim of providing a better performance of execution
  • Figure 4 is a block diagram of a compilation device according to the invention.
  • the general principle of the invention lies in the combination of a static approach to the compilation, making it possible to create applications optimized computing by performing a compilation (prior to the execution of the application) while maintaining an execution based on the implementation of virtual machines.
  • a compilation prior to the execution of the application
  • an execution based on the implementation of virtual machines one of the problems of applications that work with virtual machines.
  • one of the problems of applications that work with virtual machines is performance.
  • the principle behind the use of virtual machines is to allow portability of the intermediate code (from one or more source code compilations) on any hardware platform having a virtual machine capable of executing the virtual code. intermediate code in question.
  • the invention thus relates to a compilation technique for virtual machine-based runtime environments that provides a better performance of execution.
  • the principle of improving performance relies on moving the execution of some parts of intermediate code in the form of binary code much more powerful, while remaining under the control of execution of the application by the target virtual machine.
  • the compilation is based on the source (or intermediate) code of the application.
  • the compiler performs code generation comprising two parts: a first set of intermediate code that executes by implementing the virtual machine and a second set of binary code that executes directly by the processor of the hardware platform.
  • Figure 3 describes the principle of the invention.
  • the invention allows the developer to select (101) from a source code or an intermediate code 100 the code parts to compile in binary code.
  • the compiler 102 generates the codes (103, 104, 106 and 107) for executing the code portions chosen by the developer in binary code.
  • the generated codes (103, 104, 106 and 107) will be executed by the virtual machine 105, thanks to its binary code execution support 1 16.
  • the virtual machine runs over the operating system 108 , itself running on a hardware platform 109.
  • the invention allows the developer to choose the pieces of source code to perform with great performance, without additional manual integration operation.
  • the integration to the virtual machine is transparent. There is no modification of the virtual machine.
  • the performance of the final code depends on the binary code execution support of the virtual machine.
  • the integration is compatible with a dynamic compilation solution of a virtual machine. This integration makes it possible to cumulate the performances.
  • the binary code can be loaded dynamically, or embedded according to the possibilities of the virtual machine.
  • the invention also makes it possible to have different granularities of compilation: method, application, service, APIs, or piece of code.
  • the fact of having different granularities of compilation makes it possible to precisely target the parts of code to be accelerated according to the cases.
  • the compilation method of the invention is implemented prior to the execution of the application on the platform. Having no resource constraints, the compiler can thus use aggressive optimizations very advanced to generate the binary code or intermediate code that will further improve the performance of the application.
  • a set of specific codes linking the two sets is integrated with the two sets of codes generated using a native interface of the virtual machine.
  • the use of a native interface positively impacts the degree of performance improvement obtained (depending on the interface used).
  • the compiler uses one of the native interfaces available by the virtual machine.
  • this native interface can be either the standard native interface of the virtual machine to link with native libraries (for example a JNI interface), or one of the most powerful internal interfaces.
  • the dependence between the binary application part and the virtual machine lies in the native interface of the latter. Sometimes this native interface does not need to be modified, sometimes it has to be modified to get the desired performance improvement.
  • the compilation method since the compilation method relies on one of the native interfaces of the virtual machine, it makes it possible to keep the object system of the target virtual machine without having to modify it.
  • this interfacing structure is in one particular embodiment one or more global variables of the binary application part.
  • a global variable includes a pointer that points to an address (in memory) for accessing objects or data structures managed by the virtual machine for the application.
  • Another example is when compiling to obtain the set of binary codes, to introduce in it another set of referencing instructions allowing, during the execution of the application, to create an interfacing structure to an array of referencing objects used by the binary application part.
  • This object referencing table is part of the data that is managed by the application part. Indeed, during the execution of the application, the objects being shared between the virtual machine and the binary application part, it is necessary that the latter knows the objects that are used by the binary application part to prevent the "garbage" collector "of the virtual machine does not delete objects used by the binary application part. It is therefore necessary that the virtual machine can get acquainted with the objects used by the binary application part within the memory space allocated to the application part.
  • the addition, during the generation of code sets, referencing structures allows the virtual machine to ensure that it does not delete objects used by the binary part.
  • the use of a second object system making it possible to execute the binary code without having to use the native interface of the virtual machine is also possible in order to improve performance even more.
  • the quasi-totality of an application can be compiled into binary code by using a specific object system.
  • the set of intermediate codes generated is minimal and allows the virtual machine to perform the minimum of operation required to execute the application such as launching, terminating or suspending the execution of the application on the terminal.
  • the basis of the method of compiling a set of source or intermediate code into two sets of codes is automatic.
  • the entire process can be completely automatic, or include complementary manual phases.
  • the binary code occupies a more important place in memory than the intermediate code. Indeed, it is intended to take into account the memory size constraints of the terminal.
  • the method allows, in at least one embodiment, to select the code parts to be compiled.
  • the developer of the application masters the code expansion in view of the memory constraints of the target terminal.
  • the compiler can also decide for itself the cutting of the codes to be performed using a particular optimization that makes it possible to achieve a memory / performance expansion compromise automatically.
  • the method is compatible with an interpreted target virtual machine.
  • This virtual machine can also have a dynamic compiler that will improve the performance of the intermediate code.
  • the performance improvements are cumulative (initial with the method of the invention and dynamic with the dynamic compiler).
  • the method is not restricted to applications and can be used for source or intermediate code of an application, service or library to be executed by the virtual machine.
  • the method can be used on all code sets of an application, or a particular code portion, without granularity limit (a class, a method, or a piece of code of a method ).
  • the implementation of the invention is presented for an Android TM runtime environment.
  • Google's Android TM runtime environment is based on a Linux TM operating system distribution that includes libraries, a virtual machine called Dalvik TM, and intermediate code. This intermediate code includes applications, system services and embedded libraries on the platform. Source codes for applications, services and libraries are written in JAVA TM and compiled into Dalvik TM intermediate code.
  • the particularity of Android TM is that it is adapted to the operation of light terminals with, compared to current personal computers, low execution capabilities.
  • the Dalvik TM virtual machine has the particularity of being based on a "register-based virtual machines” architecture unlike other virtual machines that are called “stack” (from the "register-based virtual machines”). stack based virtual machines).
  • stack-based virtual machines must use the instructions to load data on the stack and manipulate the data, and therefore require more instructions than "register” machines to implement code at the same level, but the instructions in a "register” machine must encode the source and destination registers and, therefore, tend to be larger.
  • the compilation chain of Andro ⁇ d TM for the Java language compiles intermediate code java code using two compilers. The first compiles java source code into Java intermediate code (ByteCode Java). The second compiles the java intermediate code (ByteCode Java) into Dalvik intermediate code (.dex file). So we have a chain of two successive compilations to come up with an executable code ".dex" on an Andro ⁇ d TM platform from a source code written in java. In the Android TM platform, to improve performance, the implementation of the invention is as follows:
  • the initial java source code CSj is compiled using the java compiler of the Android TM platform to produce a first set of intermediate code (ByteCode Java) Clj, which is, in this embodiment, the code to be compiled.
  • the intermediate code Clj is compiled selectively to obtain two distinct sets of code: a first set of source code C / C ++ CSc l and a second set of intermediate code Clj 2.
  • the second set of intermediate code CIj2 is compiled into Dalvik TM intermediate code using the compiler available in the Andro ⁇ d TM compilation chain in order to produce the ".dex" application executable on the platform via the Dalvik TM virtual machine.
  • the first set of CScl source code including C / C ++ code
  • the first set of CScl source code is compiled using the C / C ++ compiler available in the Android TM compilation chain to generate binary code that is in the form of dynamic libraries Linux TM, to produce the second part of the application.
  • JNI Java Native Interface
  • framework development framework
  • Java Byte Code running inside a java virtual machine. call (and be called) by so-called native applications or libraries running in binary code.
  • This JNI interface is widely used in Java environments. Also, in order to link the execution of the two types of codes generated (on the one hand the Dalvik TM code and on the other hand the Linux TM dynamic libraries, the compiler of the invention adds specific JNI codes allowing to execute the two parts. Thus, the invention makes it possible to compile Java parts in native code, while keeping intermediate code parts, while linking the execution of the two parts of the application using the Dalvik TM JNI interface. .
  • Another implementation of the invention may also consist in using the internal native interface of the Dalvik TM virtual machine to avoid the use of the JNI interface, which itself may pose some performance problems.
  • the Dalvik TM virtual machine remains master of the execution and its object execution model remains preserved and used to execute the application.
  • This object execution model is in charge of the management of fields, methods, associated memory.
  • the invention thus makes it possible to benefit from a high-performance binary code that executes within the virtual machine.
  • Each processor of the hardware platform has an associated memory architecture. This can be composed of several levels of memory cache, specific memory (direct access, ROM, ...), additional RAM or flash, different timing frequencies.
  • the performance of the processor will be a function of the location of the instructions and data of an application in its memory hierarchy.
  • the processor makes it possible to have two memory access channels in parallel. One for the instructions, the other for the data. These two channels are also optimized and calibrated according to the distribution of instructions and data access.
  • the intermediate code is considered to be data. Also, all the memory accesses pass through the same channel, which penalizes the operation of the memory architecture and impacts the execution performance.
  • Dynamic compilers generate binary code that can be loaded by the instruction channel. Also, they allow to use both channels memory access in parallel. However, this binary code is in a RAM, preventing the use of ROM, resident near the processor.
  • the compiler can execute upstream of the integration of the terminal, the binary code can be placed in a read-only memory close to the processor. This allows :
  • the invention is in the form of a device capable of implementing the compilation method as described above. Such a device is schematically described in relation to FIG. 4.
  • the processing unit 42 receives as input, via an input interface module I, a set of codes to be compiled, which the microprocessor processes, according to the instructions of the aforementioned program, to generate an application composed of two parts. This two-part application is delivered via the T interface.
  • the device comprises means of selective compilation of the set of codes to compile delivering a compiled application comprising a first application part executed by said virtual machine by using instructions of said virtual machine and a second application part comprising binary instructions directly executable on said hardware platform.
  • the selective compilation means comprise means for selecting the subsets of codes to be compiled. These selection means are either implemented manually or implemented automatically. An automatic implementation of the selection may be performed by a code pre-analysis device 43 for identifying those portions of code for which optimization and / or binary execution is preferable.
  • the selective compilation means furthermore comprise at least two compilation devices which make it possible on the one hand to generate the first part of the application, which is executed by the virtual machine and the second part of the application, which is executed directly. by the operating system of the hardware platform.
  • These two compilation devices can be complemented by other devices, such as other compilers, linkers, or optimizers.

Abstract

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.

Description

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 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 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, 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 : - 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. C'est le cas pour le langage Java™ 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 mettre en œuvre 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 Java™, 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. II 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. Il 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 Android™ 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 cœur d'exécution du système, comme c'est le cas pour le système Android™, 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 à 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, 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 :
- 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.
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 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 autre approche, cette structure d'interfaçage peut être une structure particulière permettant de réaliser un lien avec une interface interne, plus performante, de la machine virtuelle.
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 œuvre 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 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 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 œuvre du procédé de navigation tel que décrit précédemment, lorsque ce 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 ê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 œuvre 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 1 16. 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 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 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.
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 :
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 œuvre 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 d'une interface native impacte positivement le degré d'amélioration de performance obtenu (en fonction de l'interface utilisée). 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 (par exemple une interface JNI), soit une des interfaces internes plus performantes. Ainsi, il n'est pas nécessaire de prévoir un ensemble de codes spécifiques pour lier l'ensemble de codes intermédiaires et l'ensemble de codes binaires.
Selon une caractéristique particulière, la dépendance entre la partie applicative binaire 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.
Ainsi, par exemple, il est prévu, lors de la compilation permettant d'obtenir l'ensemble de codes binaires, d'introduire au sein de celui-ci un ensemble d'instructions permettant l'accès au système objet de la machine virtuelle. Cet ensemble d'instructions, appelé ensemble d'instructions de référencement, permet, lors de l'exécution de l'application, de créer une structure d'interfaçage de la partie applicative binaire (qui correspond à l'ensemble de codes binaires) avec la machine virtuelle. Plus particulièrement, cette structure d'interfaçage est dans un mode de réalisation particulier une ou plusieurs variables globales de la partie applicative binaire. Une variable globale comprend un pointeur qui pointe vers une adresse (en mémoire) d'accès à des objets ou des structures de données gérés par la machine virtuelle pour l'application. Ainsi, dans ce mode de réalisation il n'y a qu'un seul ensemble d'objets ou structures de données, commun à la fois à l'ensemble de codes intermédiaires et l'ensemble de codes binaires. Un autre exemple consiste lors de la compilation permettant d'obtenir l'ensemble de codes binaires, d'introduire au sein de celui-ci un autre ensemble d'instructions de référencement permettant, lors de l'exécution de l'application, de créer une structure d'interfaçage vers un tableau de référencement des objets utilisés par la partie applicative binaire. Ce tableau de référencement des objets fait partie des données qui sont gérées par la partie applicative. En effet, lors de l'exécution de l'application, les objets étant partagés entre la machine virtuelle et la partie applicative binaire, il est nécessaire que cette dernière connaisse les objets qui sont utilisés par la partie applicative binaire pour éviter que le « garbage collector » de la machine virtuelle ne supprime des objets utilisés par la partie applicative binaire. Il est donc nécessaire que la machine virtuelle puisse aller prendre connaissance des objets utilisés par la partie applicative binaire au sein de l'espace mémoire alloué à la partie applicative. L'ajout, lors de la génération des ensembles de code, des structures de référencement, permet d'autoriser la machine virtuelle à s'assurer qu'elle ne supprime pas des objets utilisés par la partie binaire.
Dans un autre mode de réalisation 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 codes intermédiaires 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 se 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 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 méthode).
Par la suite on décrit une mise en œuvre de l'invention adaptée à la plateforme Androïd™. Il est évident que l'invention n'est nullement limitée à cette plateforme particulière mais peut également être mise en œuvre 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 œuvre de l'invention pour un environnement d'exécution Android™.
L'environnement d'exécution Android™ de Google™ est basé sur une distribution du système d'exploitation Linux™ auquel sont ajoutées des librairies, une machine virtuelle qui se nomme Dalvik™ 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 JAVA™, puis compilés en code intermédiaire Dalvik™. La particularité d'Android™ 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 Dalvik™ 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 œuvre 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ïd™ 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ïd™ à partir d'un code source écrit en java. Dans la plateforme Android™, pour améliorer les performances, la mise en œuvre de l'invention est la suivante :
le code source java initial CSj, est compilé à l'aide du compilateur java de la plateforme Android™ afin de produire un premier ensemble de code intermédiaire (ByteCode Java) Clj, qui est, dans ce mode de réalisation, le code à compiler.
puis, le code intermédiaire Clj est compilé de façon sélective pour obtenir deux ensembles de code distincts : un premier ensemble de code source C/C++ CSc l et un deuxième ensemble de code intermédiaire Clj 2.
plus précisément, le deuxième ensemble de code intermédiaire CIj2 est compilé en code intermédiaire Dalvik™ à l'aide du compilateur disponible dans la chaîne de compilation Androïd™ afin de produire l'application « .dex » exécutable sur la plateforme par l'intermédiaire de la machine virtuelle Dalvik™.
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 Android™ afin d'en générer du code binaire qui se présente sous la forme de librairies dynamiques Linux™, afin de produire la deuxième partie de l'application.
La machine virtuelle Dalvik™ 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 Dalvik™ et d'autre part les librairies dynamiques Linux™, 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 Dalvik™.
Une autre implémentation de l'invention peut également consister à utiliser l'interface native interne de la machine virtuelle Dalvik™ 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 Dalvik™ 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'accroître 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 œuvre 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 œuvre de manière manuelle soit mis en œuvre automatiquement. Une mise en œuvre 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.

Claims

REVENDICATIONS
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.
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.
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.
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.
Procédé selon la revendication 4, caractérisé en ce que ladite phase de compilation 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.
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.
Procédé selon la revendication 1, caractérisé en ce que ledit ensemble de codes à compiler est un ensemble de « ByteCode » Java.
Procédé selon la revendication 1, caractérisé en ce que ledit ensemble de codes à compiler est un ensemble de « ByteCode » Dalvik.
Procédé selon la revendication 1 , caractérisé en ce que ledit ensemble de codes à compiler est un ensemble de codes Java.
Procédé selon la revendication 1 , caractérisé en ce qu'il est mis en œuvre préalablement à une exécution de ladite application logicielle au sein de ladite machine virtuelle.
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 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.
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.
EP11728266.5A 2010-06-29 2011-06-27 Procédé de compilation sélective, dispositif et produit programme d'ordinateur correspondant Withdrawn EP2588953A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1055261A FR2961922B1 (fr) 2010-06-29 2010-06-29 Procede de compilation selective, dispositif et produit programme d'ordinateur correspondant.
PCT/EP2011/060748 WO2012000949A1 (fr) 2010-06-29 2011-06-27 Procédé de compilation sélective, dispositif et produit programme d'ordinateur correspondant

Publications (1)

Publication Number Publication Date
EP2588953A1 true EP2588953A1 (fr) 2013-05-08

Family

ID=43465985

Family Applications (1)

Application Number Title Priority Date Filing Date
EP11728266.5A Withdrawn EP2588953A1 (fr) 2010-06-29 2011-06-27 Procédé de compilation sélective, dispositif et produit programme d'ordinateur correspondant

Country Status (4)

Country Link
US (2) US9535672B2 (fr)
EP (1) EP2588953A1 (fr)
FR (1) FR2961922B1 (fr)
WO (1) WO2012000949A1 (fr)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8813048B2 (en) * 2009-05-11 2014-08-19 Accenture Global Services Limited Single code set applications executing in a multiple platform system
US9430200B1 (en) 2015-06-04 2016-08-30 Microsoft Technology Licensing Llc Cross-library framework architecture feature sets
US10120664B2 (en) 2015-08-28 2018-11-06 International Business Machines Corporation Incremental build generation
CN109445772B (zh) * 2018-12-29 2022-05-24 山东劳动职业技术学院（山东劳动技师学院） 一种面向智能手机的软件应用框架及其开发系统
US10956137B2 (en) 2019-06-10 2021-03-23 International Business Machines Corporation Compiling source code using source code transformations selected using benchmark data
CN110275713A (zh) * 2019-07-02 2019-09-24 四川长虹电器股份有限公司 一种Java虚拟机后端编译的改进方法
US11397568B2 (en) * 2019-12-10 2022-07-26 International Business Machines Corporation Escape analysis support for method redefinition
US11194554B2 (en) * 2020-04-28 2021-12-07 International Business Machines Corporation Efficient quantum adaptive execution method for quantum circuits
CN115495086A (zh) * 2022-08-31 2022-12-20 蚂蚁区块链科技(上海)有限公司 一种编译方法和编译器、Wasm虚拟机

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US653156A (en) * 1899-07-25 1900-07-03 Elliott Toxey Apparatus for transmitting sounds.
US3859636A (en) * 1973-03-22 1975-01-07 Bell Telephone Labor Inc Microprogram controlled data processor for executing microprogram instructions from microprogram memory or main memory
JPS61182160A (ja) * 1985-02-06 1986-08-14 Toshiba Corp デ−タ処理装置
GB2283596B (en) * 1993-11-01 1998-07-01 Ericsson Ge Mobile Communicat Multiprocessor data memory sharing
JP2738365B2 (ja) * 1995-10-18 1998-04-08 日本電気株式会社 マイクロコンピュータ用プログラム変換方法及びそのプログラムを用いたマイクロコンピュータ
US6321323B1 (en) * 1997-06-27 2001-11-20 Sun Microsystems, Inc. System and method for executing platform-independent code on a co-processor
US6513156B2 (en) * 1997-06-30 2003-01-28 Sun Microsystems, Inc. Interpreting functions utilizing a hybrid of virtual and native machine instructions
US6163836A (en) * 1997-08-01 2000-12-19 Micron Technology, Inc. Processor with programmable addressing modes
US6141732A (en) * 1998-03-24 2000-10-31 Novell, Inc. Burst-loading of instructions into processor cache by execution of linked jump instructions embedded in cache line size blocks
US6289506B1 (en) * 1998-06-30 2001-09-11 Intel Corporation Method for optimizing Java performance using precompiled code
US6253215B1 (en) * 1998-08-17 2001-06-26 Sun Microsystems Method, apparatus, and article of manufacture for facilitating resource management for applications having two types of program code
GB9825102D0 (en) * 1998-11-16 1999-01-13 Insignia Solutions Plc Computer system
US6295643B1 (en) * 1998-12-10 2001-09-25 International Business Machines Corporation Method and apparatus for improving java virtual machine performance using persistent execution information
US6629113B1 (en) * 1999-06-30 2003-09-30 International Business Machines Corporation Method and system for dynamically adjustable and configurable garbage collector
US6295642B1 (en) * 1999-04-29 2001-09-25 International Business Machines Corporation Method and apparatus for partial just in time compiling in a data processing system
US6851109B1 (en) * 1999-05-06 2005-02-01 International Business Machines Corporation Process and system for dynamically compiling a partially interpreted method
US6754828B1 (en) * 1999-07-13 2004-06-22 Intel Corporation Algorithm for non-volatile memory updates
US6484188B1 (en) * 1999-12-30 2002-11-19 Intel Corporation Optimization of garbage collection code in the context of raw native interface function calls in the java programming language
EP1211598A1 (fr) * 2000-11-29 2002-06-05 Texas Instruments Incorporated Appareil, système et méthode de traitement de données
US7213240B2 (en) * 2001-10-05 2007-05-01 Sun Microsystems, Inc. Platform-independent selective ahead-of-time compilation
US7150012B2 (en) * 2002-10-15 2006-12-12 Nokia Corporation Method and apparatus for accelerating program execution in platform-independent virtual machines
WO2004040445A1 (fr) * 2002-10-29 2004-05-13 Freescale Semiconductor, Inc. Procede et appareil d'optimisation selective de code de langage interprete
US7203941B2 (en) * 2002-11-14 2007-04-10 Microsoft Corporation Associating a native resource with an application
US7275241B2 (en) * 2003-11-21 2007-09-25 International Business Machines Corporation Dynamic instrumentation for a mixed mode virtual machine
US7788657B2 (en) * 2004-02-27 2010-08-31 Tvworks, Llc Targeted runtime compilation
US7489946B2 (en) * 2005-04-14 2009-02-10 Sudharshan Srinivasan Cellular phone in form factor of a conventional audio cassette
US8296745B2 (en) * 2007-12-31 2012-10-23 Oracle America, Inc. Method and apparatus for portable stub generation
US20100153675A1 (en) * 2008-12-12 2010-06-17 Microsoft Corporation Management of Native Memory Usage
US8407573B2 (en) * 2009-10-09 2013-03-26 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for equalization of received signals
ES2702470T3 (es) * 2009-11-05 2019-03-01 Gemalto Sa Objeto portátil seguro
JP5466601B2 (ja) * 2010-08-31 2014-04-09 インターナショナル・ビジネス・マシーンズ・コーポレーション コード生成方法、システム及びプログラム
US9141540B2 (en) * 2010-11-12 2015-09-22 International Business Machines Corporation Garbage collection of interned strings

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2012000949A1 *

Also Published As

Publication number Publication date
US20170075667A1 (en) 2017-03-16
WO2012000949A1 (fr) 2012-01-05
US20130311980A1 (en) 2013-11-21
US10216497B2 (en) 2019-02-26
FR2961922A1 (fr) 2011-12-30
US9535672B2 (en) 2017-01-03
FR2961922B1 (fr) 2013-12-13

Similar Documents

Publication Publication Date Title
WO2012000949A1 (fr) Procédé de compilation sélective, dispositif et produit programme d'ordinateur correspondant
EP2649523B1 (fr) Méthode de compilation d'un code intermédiaire d'une application
US8726255B2 (en) Recompiling with generic to specific replacement
US8108848B2 (en) Automatic and transparent memoization
US11354159B2 (en) Method, a device, and a computer program product for determining a resource required for executing a code segment
EP1212678B1 (fr) Protocole de gestion, procede de verification et de transformation d'un fragment de programme telecharge et systemes correspondants
EP2649522B1 (fr) Methode de mise a disposition d'une application en tant que librairie dans une machine virtuelle
US20200065124A1 (en) Shortening just-in-time code warm up time of docker containers
EP2649520B1 (fr) Distribution d'application délivrant une application dédiée à un terminal à partir d'une application déposée par le développeur
KR20140046402A (ko) 라이브러리 운영체제들과의 애플리케이션 호환성
EP2862066A1 (fr) Bibliothèques portables adaptatives
US20150294114A1 (en) Application randomization
WO2018154197A1 (fr) Procédé, équipement et système de gestion du système de fichiers
EP1649363B1 (fr) Procede de gestion des composants logiciels integres dans un systeme embarque
Ernstsson et al. Extending smart containers for data locality‐aware skeleton programming
WO2007068706A1 (fr) Procede pour securiser l'execution d'un code logiciel en langage intermediaire dans un appareil portatif
FR2871590A1 (fr) Procede de chargement d'un logiciel en langage intermediaire oriente objet dans un appareil portatif.
Courbot et al. Efficient off-board deployment and customization of virtual machine-based embedded systems
EP2252933B1 (fr) Architecture de traitement informatique accelere
WO2021130420A1 (fr) Procédé et dispositif mettant en œuvre ce procédé pour générer et installer un code exécutable dans la mémoire d'un noyau d'une machine virtuelle depuis un hyperviseur
FR3074939A1 (fr) Procede de gestion du systeme de fichiers d'un terminal informatique
US20120102473A1 (en) Abstract method removal for reduced memory footprint with optimizer tool
WO2019180376A1 (fr) Procédé et système pour créer une image d'une application
EP3411821B1 (fr) Procédé de stockage de contenus, procédé de consultation de contenus, procédé de gestion de contenus et lecteurs de contenus
FR3087916A1 (fr) Procede de traitement d'un code source, dispositif, systeme et programme correspondant

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20130128

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20170908

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: GOOGLE INC.

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: GOOGLE LLC

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20190514

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230519