CN115543326A

CN115543326A - Application program running method and device

Info

Publication number: CN115543326A
Application number: CN202110713902.XA
Authority: CN
Inventors: 季柯丞; 邱榆; 彭卓立; 李文韬
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-06-25
Filing date: 2021-06-25
Publication date: 2022-12-30

Abstract

The embodiment of the application discloses an application program running method and device, relates to the field of electronic equipment, and can avoid repeated JIT compiling and storing of the same function, so that the use efficiency of machine codes obtained by JIT compiling is improved. The specific scheme is as follows: the first application is loaded in a first process. The first function is interpreted in the first process. And compiling the first function after the number of times of interpreting and executing the first function reaches a first compiling threshold value of the first function in the first process. And storing the result of the compiling performed by the first function in a shared code cache, wherein the shared code cache is accessible to at least the process in the electronic equipment.

Description

Application program running method and device

Technical Field

The embodiment of the application relates to the field of electronic equipment, in particular to an application program running method and device.

Background

For interpreted languages, such as JAVA, perl, python, MATLAB, etc., the interpreted language may be converted into a higher-level programming language in advance into more efficient bytecode, which is an intermediate code independent of a target platform, and may be interpreted and executed, or may be run in a processor directly supporting bytecode, and then the electronic device performs line-by-line interpretation and execution on the bytecode by way of interpretation and execution, so as to implement the execution of the application program, where the efficiency of interpretation and execution on the bytecode is lower than that of directly executing compiled native machine code, and in order to improve the execution efficiency, technicians have proposed Just-in-time compilation (Just-in-time compilation) technology, i.e., compiling the bytecode into native machine code in operation and executing, and research and development personnel have focused on optimizing the application of Just-in-time compilation (Just-in-time compilation) technology continuously on performance and memory usage.

Disclosure of Invention

The embodiment of the application provides an application program running method and device, which can avoid multiple JIT compiling and storing of the same function, thereby improving the use efficiency of machine codes obtained by JIT compiling and improving the running efficiency of electronic equipment.

In order to achieve the above purpose, the embodiment of the present application adopts the following technical solutions:

in a first aspect, a method for running an application program is provided, where the method is applied to an electronic device, and a first application program is installed in the electronic device, and the first application program includes a first function, and the method includes: the first application is loaded in a first process. The first function is interpreted in the first process. And compiling the first function after the number of times of interpreting and executing the first function reaches a first compiling threshold value of the first function in the first process. And storing the result of the compiling performed by the first function in a shared code cache, wherein the shared code cache is accessible to at least the process in the electronic equipment.

Based on this scheme, a mechanism for sharing code is provided. In this example, the electronic device may store the compiled machine code in the shared code cache after the first function performs the compilation (e.g., JIT compilation). Wherein the shared code cache may be a space in a memory accessible by at least 2 applications in the electronic device. Thus, after the function is JIT compiled, the machine code obtained by JIT compilation may be stored in memory, and when there are other applications that need to call the function, the function may not need to be repeatedly interpreted and executed or JIT compiled, but rather the JIT compilation result of the function may be retrieved directly from the shared code cache. This can avoid wasting computing power due to multiple JIT compilations of the function and wasting memory space due to multiple stores. Therefore, the effect of improving JIT compiling can be achieved, and the operating efficiency of the electronic equipment is improved.

In a possible design, a second application program is further installed in the electronic device, where the second application program includes the first function, and the method further includes: the second application is loaded in a second process. The second process is the same as the parent process of the first process. When the first function is called in the second process, the result of compiling the first function is read and executed from the shared code cache. Based on the scheme, a shared code cache using mechanism is provided. In this example, when the second process corresponding to the second application needs to use the first function, the JIT compilation result of the first function can be directly read from the shared code cache, thereby avoiding duplicate JIT compilation and storage. It should be noted that, in this example, the storage address of the shared code cache may be configured in a parent process of all processes such as the zygate process, so that different processes may obtain the same virtual address for the shared code cache in different processes by integrating the description files configured in the zygate process when being established, thereby implementing correct call of different processes to the shared code cache.

In a possible design, the electronic device stores a first function state record table, where the first function state record table is used to record storage addresses of different functions after compiling, and the second process reads and executes a result of the first function performing compiling from the shared code cache, where the method includes: and reading the first function state record table in the second process, and searching whether a storage address corresponding to the first function exists in the first function state record table according to the function signature of the first function. And when the storage address corresponding to the first function exists, reading the compiled machine code of the first function from the storage address, and executing the compiled machine code of the first function. Based on the scheme, a specific example of obtaining the compilation result of the first function in the shared code cache is provided. In this example, the electronic device may record the address stored in the shared code cache after compiling by setting a first function state record table. Therefore, when the machine code acquired by JIT compiling of the first function needs to be called, different processes can search the first function state record table according to the first function signature to acquire the storage address of the machine code of the first function. The process may then retrieve and execute the machine code of the first function from the memory address.

In one possible design, before the first process stores a result of the first function performing the compilation in a shared code cache, the method further includes: the first process establishes/updates the memory address of the first function after compiling in the first function state record table. Based on the scheme, an updating mechanism of the first function state record table is provided. In this example, after compiling the first function, the first process in the electronic device updates the compiled condition to the first function state record table, so that when a subsequent process calls the first function, the machine code of the first function can be obtained by looking up the first function state record table.

In a possible design, when the memory address corresponding to the first function does not exist in the first function state record table, the method further includes: the execution of the first function is interpreted in the second process. Based on the scheme, a scheme example is provided when the machine code of the first function is not included in the first function state record table. For example, when the machine code of the first function is not stored in the shared code cache, the second process may directly perform interpreted execution on the first function, thereby implementing execution of the first function.

In one possible design, prior to performing the compilation of the first function in the first process, the method further includes: it is determined that the first function was invoked by a plurality of different processes. Based on the scheme, a possible condition for compiling the first function and putting the first function into the shared code cache is provided. It can be understood that the machine code in the shared code cache may be called by a plurality of different processes, and therefore, before the machine code is stored in the shared code cache, the electronic device may determine that a function corresponding to the machine code will be called by a plurality of processes, thereby avoiding a situation where the machine code in the shared code cache will be called by only 1 process, and thus improving the usage rate of the machine code in the shared code cache.

In one possible design, a function access record table corresponding to the first function is stored in the electronic device. The determining that the first function is called by a plurality of different processes includes: and reading the function access record table, and determining that the first function is called by a plurality of different processes according to the fact that at least one third process calls the first function in the function access record table. The third process is different from the first process. Based on this scheme, a scheme is provided for determining that the first function can be called by a plurality of different processes. In this example, each function may be configured with a function access record table. When calling a function, different processes can mark the function access record table of the function, so that other processes can determine that the function has been called by other processes according to the function access record table. It will be appreciated that if a first function needs to be JIT compiled and placed into the shared code cache, the log may be accessed by querying the function of the first function, indicating that the first function will be called by a plurality of different processes if the plurality of different processes are identified in the log to access the first function.

In one possible design, the method further includes: when the third process calls the first function, establishing/updating a first table entry corresponding to the first function in the function access record table, wherein the first table entry is used for indicating the times of calling the first function by the third process. Based on the scheme, a mechanism for updating the function access record table is provided. In this example, each time the process calls the first function, the corresponding entry may be updated/created in the function state record table of the first function.

In one possible design, the method further includes: when the first process calls the first function, a second table entry corresponding to the first function is established/updated in the function access record table, wherein the second table entry is used for indicating the times of calling the first function by the first process. Based on the scheme, another mechanism for updating the function access record table is provided. In this example, when a process different from other processes calls the first function 1 time, the corresponding second entry may be newly created/updated in the function access record table of the first function, so as to identify that the process calls the first function.

In one possible design, no inline optimization is used in the compilation process. Based on this scheme, the compilation process of machine code placed into a shared code cache may be optimized or not optimized with inlining. This ensures that the JIT compiled machine code will be able to run correctly in different processes.

In one possible design, the method further includes: after the number of times of interpreting and executing the first function in the first process reaches a second compiling threshold value of the first function, compiling the first function, and storing a result of compiling the first function in a private code cache of the first process. Based on the scheme, when the first process uses the first function, compiling of the first function stored in the private code cache can also be triggered. It is understood that when the first process calls the first function for a greater number of times, the first function may be subjected to JIT compilation using inline optimization, and the machine code thus obtained may be more suitable for running in the virtual machine of the first function. Therefore, the use efficiency of the first function in the first process can be further improved.

In one possible design, the method further includes: in the first process, when the first function is called again, the machine code obtained by compiling the first function is read and executed from the private code cache. Based on the scheme, a mechanism for using the machine code in the private code cache is provided. It will be appreciated that when the first function is called multiple times, then the first process may JIT compile it and store the results in the private code cache. The machine code stored in the private code cache can only be called by the first process. The machine code may be JIT compiled machine code that is optimally obtained for the virtual machine environment of the first process using optimization means including inline optimization. Therefore, when the first function is called again, the optimized machine code can be called from the private code cache directly for running, and therefore the running efficiency of the first function is improved.

In a possible design, the electronic device stores a second function state record table, where the second function state record table is used to record the memory address of a different function after compilation in the first process, and the machine code obtained by compiling and executing the first function is read from the private code cache and includes: and reading the second function state record table in the first process, and searching whether a storage address corresponding to the first function exists in the second function state record table according to the function signature of the first function. And when the storage address corresponding to the first function exists, reading the compiled machine code of the first function from the storage address, and executing the compiled machine code of the first function. Based on this scheme, an example is provided of retrieving optimized JIT compiled machine code from a private code cache. In this example, a second function-state record table corresponding to a private code cache may be configured in the electronic device, similar to the previous scheme of retrieving JIT-compiled machine code from a shared code cache. By inquiring the signature of the first function in the second function state record table, the storage address of the machine code of the first function in the private code cache can be obtained, and further the first process can call the machine code of the first function to execute.

In one possible design, before storing a result of the compiling of the first function execution in a private code cache of the first process, the method further includes: the first process establishes/updates the memory address of the first function after compiling in the second function state record table. Based on the scheme, a thinner mechanism of the second function state record table is provided.

In a possible design, when the storage address corresponding to the first function does not exist in the second function state record table, the method further includes: and reading the first function state record table in the first process, and searching whether a storage address corresponding to the first function exists in the first function state record table according to the function signature of the first function. And when the storage address corresponding to the first function exists, reading the compiled machine code of the first function from the storage address, and executing the compiled machine code of the first function. Based on this scheme, a call logic is provided for an electronic device to perform JIT compilation of a first function while storing it in a shared code cache and to compile machine code as stored in a private code cache through optimized JIT. It will be appreciated that the optimized JIT compiled machine code is more efficient for the first process, and thus the first process may determine that the first function is absent from the second function state record table, i.e., absent the optimized JIT compilation, and then call the machine code in the shared code cache.

In a possible design, when the storage address corresponding to the first function does not exist in the first function state record table, the method further includes: the first function is interpreted in the first process. Based on the scheme, the first function can be executed in an interpreted execution mode if the first function is not compiled.

In one possible design, the method further includes: and the electronic equipment executes garbage collection on the shared code cache according to the load condition of the memory. Based on the scheme, a garbage collection mechanism of the shared code cache is provided. In the scheme, the electronic device can manage the machine codes in the shared code cache according to the load condition of the memory.

In one possible design, the load condition of the memory includes a light memory load and a heavy memory load. When the usage rate of the memory is higher than a first threshold and lower than a second threshold, the electronic device determines that the load condition of the memory is a memory light load, and performs garbage collection on the shared code cache, including: and the electronic equipment sequentially executes garbage collection on machine codes obtained by compiling the functions which are not called in the first function state record table. Based on the scheme, a specific mechanism for managing the machine code in the shared code cache is provided. For example, garbage collection of machine codes in the shared code cache may be triggered according to the overload, underload, and other states of the memory of the electronic device. For example, the electronic device may not perform garbage collection when the memory is abundant (e.g., the usage rate is lower than the first threshold), and may perform garbage collection of the shared code cache when the memory is lightly loaded. In this example, the electronic device may perform garbage collection on machine codes that are not used in the shared code cache and release the corresponding memory when the memory is lightly loaded.

In one possible design, the load condition of the memory includes a light memory load and a heavy memory load. When the utilization rate of the memory is higher than a second threshold, the electronic device determines that the load condition of the memory is a memory reload, and the performing garbage collection on the shared code cache includes: and the electronic equipment executes garbage collection on the machine codes obtained by compiling the functions in sequence according to the sequence that the called times of the machine codes obtained by compiling the functions in the first function state record table are from small to large. Based on the scheme, the electronic equipment provides another mechanism for managing the machine code in the shared code cache. In this example, the electronic device may perform garbage collection on the machine code with a smaller calling frequency in the shared code cache in the case of a memory reload, thereby further releasing the memory space.

In a second aspect, an apparatus for running an application program is applied to an electronic device, where a first application program is installed in the electronic device, the first application program includes a first function, and the apparatus includes: and the loading unit is used for loading the first application program in the first process. And the interpretation execution unit is used for interpreting and executing the first function in the first process. And the compiling unit is used for compiling the first function after the times of interpreting and executing the first function in the first process reach a first compiling threshold value of the first function. A storage unit, configured to store a result of performing the compilation of the first function in a shared code cache, where the shared code cache is accessible to at least one process in the electronic device.

In a possible design, a second application program is further installed in the electronic device, where the second application program includes the first function, and the loading unit is configured to load the second application program in the second process. The second process is the same as the parent process of the first process. The device also comprises a reading unit which is used for reading and running the result of compiling the first function from the shared code cache when the first function is called in the second process.

In a possible design, the electronic device stores a first function state record table, where the first function state record table is used to record storage addresses of different functions after compiling, and the reading unit is used to read the first function state record table in the second process, and to search whether the storage address corresponding to the first function exists in the first function state record table according to a function signature of the first function. The device also comprises an execution unit, which is used for reading the compiled machine code of the first function from the storage address and executing the compiled machine code of the first function when the storage address corresponding to the first function exists.

In one possible design, before the first process stores a result of the first function performing the compiling in a shared code cache, the apparatus further includes: and the updating unit is used for establishing/updating the memory address of the first function after compiling in the first function state record table.

In a possible design, when the storage address corresponding to the first function does not exist in the first function state record table, the interpretation execution unit is configured to interpret and execute the first function in the second process.

In one possible design, the apparatus further includes: a determining unit, configured to determine that the first function is called by a plurality of different processes before performing compilation on the first function in the first process.

In one possible design, a function access record table corresponding to the first function is stored in the electronic device. And the reading unit is used for reading the function access record table. And the determining unit is used for determining that the first function is called by a plurality of different processes according to the fact that at least one third process calls the first function in the function access record table. The third process is different from the first process.

In a possible design, the updating unit is configured to establish/update a first table entry corresponding to the first function in the function access record table when the third process calls the first function, where the first table entry is used to indicate the number of times that the first function is called by the third process.

In a possible design, the updating unit is configured to establish/update a second entry corresponding to the first function in the function access record table when the first process calls the first function, where the second entry is used to indicate the number of times that the first function is called by the first process.

In one possible design, no inline optimization is used in the compilation process.

In a possible design, the compiling unit is configured to perform compiling on the first function after the number of times of interpreting and executing the first function in the first process reaches a second compiling threshold of the first function, and the storage unit is configured to store a result of performing compiling on the first function in a private code cache of the first process.

In a possible design, the reading unit is configured to read and execute the machine code obtained by compiling the first function from the private code cache when the first function is called again in the first process.

In a possible design, the electronic device stores a second function state record table, where the second function state record table is used to record memory addresses of different functions after compiling in the first process, and the reading unit is used to read the second function state record table in the first process, and to search whether a memory address corresponding to the first function exists in the second function state record table according to the function signature of the first function. And when the storage address corresponding to the first function exists, reading the compiled machine code of the first function from the storage address, and executing the compiled machine code of the first function.

In a possible design, before the result of compiling the first function is stored in the private code cache of the first process, the updating unit is configured to establish/update a storage address of the second function state record table after compiling the first function.

In a possible design, when the storage address corresponding to the first function does not exist in the second function state record table, the reading unit is configured to read the first function state record table in the first process, and search whether the storage address corresponding to the first function exists in the first function state record table according to the function signature of the first function. When the memory address corresponding to the first function exists, the compiled machine code of the first function is read from the memory address, and the execution unit is used for executing the compiled machine code of the first function.

In a possible design, when the storage address corresponding to the first function does not exist in the first function state record table, the interpretation execution unit is configured to interpret and execute the first function in the first process.

In one possible design, the apparatus further includes: and the garbage collection unit is used for executing garbage collection on the shared code cache according to the load condition of the memory.

In one possible design, the load condition of the memory includes a light memory load and a heavy memory load. When the utilization rate of the memory is higher than a first threshold and lower than a second threshold, the electronic device determines that the load condition of the memory is a light memory load, and the garbage collection unit is used for sequentially performing garbage collection on machine codes obtained by compiling the functions which are not called in the first function state record table.

In one possible design, the load condition of the memory includes a light memory load and a heavy memory load. When the utilization rate of the memory is higher than a second threshold, the electronic device determines that the load condition of the memory is a memory overload, and the garbage collection unit is used for sequentially performing garbage collection on the machine codes obtained by compiling the functions according to the sequence that the number of times of calling the machine codes obtained by compiling the functions in the first function state record table is as small as large.

In a third aspect, an electronic device is provided that includes one or more processors and one or more memories; one or more memories coupled to the one or more processors, the one or more memories storing computer instructions; the computer instructions, when executed by the one or more processors, cause the electronic device to perform a method of operating an application program as described above in the first aspect and any of a variety of possible designs.

In a fourth aspect, a chip system is provided, which includes an interface circuit and a processor; the interface circuit and the processor are interconnected through a line; the interface circuit is used for receiving signals from the memory and sending signals to the processor, and the signals comprise computer instructions stored in the memory; when the processor executes the computer instructions, the system-on-chip performs the method of running the application program as described above in the first aspect and in any of various possible designs.

In a fifth aspect, there is provided a computer readable storage medium comprising computer instructions which, when executed, perform a method of operating an application program as in the first aspect above and any one of various possible designs.

A sixth aspect provides a computer program product comprising instructions which, when run on a computer, enable the computer to perform a method of running an application program as in the first aspect above and any one of various possible designs in accordance with the instructions.

It should be understood that, in the technical solutions provided in the second aspect, the third aspect, the fourth aspect, the fifth aspect and the sixth aspect, technical features of the technical solutions may all correspond to the operation methods of the application program provided in the first aspect and possible designs thereof, so that similar beneficial effects can be achieved, and details are not described herein.

Drawings

FIG. 1 is a diagram illustrating the execution of a function;

FIG. 2A is a diagram illustrating the execution of yet another function;

FIG. 2B is a diagram illustrating the storage of machine code in a cache;

fig. 2C is a schematic diagram illustrating storage of machine code in a cache according to an embodiment of the present disclosure;

fig. 3 is a schematic composition diagram of an electronic device according to an embodiment of the present disclosure;

fig. 4 is a schematic diagram of a software component of an electronic device according to an embodiment of the present application

FIG. 5A is a diagram illustrating the operation of a function provided by an embodiment of the present application;

fig. 5B is a schematic diagram of a code cache according to an embodiment of the present application;

fig. 6 is a schematic flowchart of an application running method according to an embodiment of the present application;

fig. 7 is a schematic diagram of a global function access record table according to an embodiment of the present application;

fig. 8 is a flowchart illustrating a method for operating another application according to an embodiment of the present application;

fig. 9 is a schematic composition diagram of an application running apparatus according to an embodiment of the present application;

fig. 10 is a schematic composition diagram of an electronic device according to an embodiment of the present application;

fig. 11 is a schematic composition diagram of a chip system according to an embodiment of the present disclosure.

Detailed Description

In some embodiments, for an application written based on an interpreted language, the electronic device can install an installation package for the application, store an application executable in the installation package into the electronic device, the executable including bytecodes generated by the interpreted language when the application was built, and then the electronic device loads the bytecodes and interprets the installation package executing the bytecodes line by line.

Is made of an android ^TM For example, the installation package may be referred to as an Android Application Package (APK), the interpretive language is JAVA language, bytecode of JAVA language, referred to as JAVA bytecode, is interpreted and executed by a JAVA virtual machine, and for some non-JAVA languages, the installation package may also be converted into JAVA bytecode and executed in the JAVA virtual machine.

In some embodiments, the application may be written in more than one language, that is, the installation package may be generated based on multiple languages, and may include already compiled native machine code, or perform an before-run compilation (AOT) on byte code when the installation package is installed, which is not limited in this application. In some embodiments of the present application, the machine code may be a binary string that can be recognized by a processor of the electronic device. The electronic device may compile the bytecode to obtain a corresponding machine code through the compiler. The electronic equipment can also interpret the byte codes line by line through the interpreter to obtain corresponding machine codes.

In fig. 1, S101 to S103 illustrate a process of performing line-by-line interpretation execution on the bytecode of the interpretation execution language.

Combined android ^TM For example, a JAVA application is executed in the (Android) system, and when an application runs, the electronic device may read a file (such as an executable file) corresponding to the application through a running environment provided by an Android Runtime (ART). For example, the electronic device may read the bytecode in the executable file through the ART (e.g., perform S101 shown in fig. 1). Next, the electronic device may convert the bytecode in the executable file into machine code that the electronic device can recognize line by line through the interpreter, such as performing S102 shown in fig. 1).

After acquiring the machine code, the electronic device may execute the machine code acquired line by line (e.g., execute S103 shown in fig. 1), thereby completing the operation of the function. Wherein the electronic device can execute the machine code after each row of bytecode-to-machine code conversion is completed. This completes the execution of a line of code. The electronic device may convert the next line of code after completing execution of one line of code. By analogy, the interpretation execution of all the bytecodes in the multi-executable file can be realized.

It will be appreciated that the bytecode in the executable file may correspond to a plurality of different functions (or methods), and thus, interpreted execution of the bytecode in the executable file, that is, interpreted execution of a plurality of functions included in the execution file.

In some embodiments, in order to improve efficiency of an application running process, a JIT mechanism is introduced, so that an electronic device may perform JIT compilation on a function whose interpretation execution times are greater than a preset threshold to obtain a native machine code, so that when the same function is subsequently run, the native machine code of the function that has been subjected to JIT compilation can be directly executed without performing interpretation execution on the function.

For example, please refer to fig. 2A in conjunction with fig. 1. After executing S101, the electronic device may determine whether the function has been compiled before interpreting the function (e.g., executing S201). For example, the electronic device may determine that the function has been compiled if it is determined that the machine code corresponding to the function is stored in the cache. Correspondingly, the electronic device may determine that the function has not been compiled if it is determined that the machine code corresponding to the function is not available in the cache. Wherein the compilation of the function in this example may be a JIT compilation of the function by the electronic device. When the electronic device determines that the compilation of the function has been completed, the compilation result may be directly invoked. It is to be understood that the compilation result may be machine code corresponding to the function obtained by JIT compilation. Therefore, the electronic device may obtain the corresponding machine code without interpreting the function again, and execute the machine code corresponding to the function that has been compiled in advance (e.g., execute S103A). The machine code that has been compiled in advance may be the machine code corresponding to all codes (e.g., byte codes) corresponding to the function after being compiled. By executing the machine code which is compiled in advance and corresponds to the function, the execution of all the machine codes of the function can be realized. Correspondingly, when the electronic device determines that the function has not been compiled, the bytecode of the function may be interpreted and executed line by line, that is, S102 to S103B are executed.

On the basis of the above-described scheme, the electronic apparatus may further determine whether the number of interpretations reaches a JIT threshold (e.g., perform S202). In some embodiments, the electronic device may perform S202 after performing S101.

In some embodiments, the electronic device may increment the corresponding counter by 1 when performing one interpretation of the function (e.g., when performing S102). By this means, the electronic device is able to record the number of interpretations of the function. In some embodiments of the present application, the electronic device determines whether to trigger JIT compilation of a function based on the number of interpretations of the function. For example, when it is determined in S202 that the number of times of execution of the current function reaches the JIT threshold, S203 is performed, that is, the function is JIT compiled and the compilation result is stored. The compilation result may be machine code obtained after compiling all bytecodes of the function. In different implementations of the present application, the interpretation times of the function may be times of execution of the interpretation performed by the function, and the interpretation times of the function may also be times of being called.

By the scheme shown in fig. 2A, it is realized that, on the basis of the execution of the interpretation, by introducing a JIT mechanism, the electronic device can JIT compile a function which is executed by multiple interpretations, thereby saving power consumption and computational overhead brought by subsequent interpretations of the function.

It should be noted that, the machine code acquired during the interpretation execution process may be a machine code corresponding to a row of bytecodes acquired through the interpreter by using the row of bytecodes as a unit. The machine code obtained in the compiling process may be the machine code corresponding to the function obtained after compiling the multiple lines of bytecodes of the function by the compiler. The machine code obtained after compilation may be stored in the electronic device for later recall, while machine code obtained by interpreting execution is generally not stored and therefore not reused. In addition, because the machine code obtained by editing is obtained by compiling based on multi-row byte codes, the machine code is based on a global environment, and the performance of the machine code is more due to the interpretation of the executed machine code.

In some implementations, the electronic device may be implemented based on a process created for an application for execution of the application. For example, when the electronic device runs the application 1, the process 1 may be created for the application 1. In the process 1, the calling and the execution of each function in the application 1 can be completed through a plurality of different threads, so that the running of the application 1 is realized. Correspondingly, when a plurality of applications run simultaneously, the electronic device may respectively create a corresponding process for each application. For example, the running applications include application 1, application 2, and application 3. The electronic device may create process 1 for application 1, process 2 for application 2, and process 3 for application 3, respectively.

In addition, the electronic device may further allocate a segment of memory for each application, so that in the process of running the corresponding application, the process of the application may store data in the allocated memory.

For example, a section of memory allocated by the electronic device for each application is called a code cache (code cache). The electronic device may allocate a code cache 1 for application 1. In this way, process 1 can use the storage resource provided by code cache 1 to achieve fast reading and writing of data. For example, after completing JIT compilation on the function M according to the scheme shown in fig. 2A to obtain the machine codes of the functions called by the application 1 during the running process, the process 1 may store the machine codes of the functions in the code cache 1, so that during the subsequent processing of the process 1, if the function needs to be called again, the machine codes of the functions are read and executed from the code cache 1, and the function is run quickly. Similarly, the electronic device may allocate a code cache 2 to the application 2, so that the process 2 may use the storage resource provided by the code cache 2.

It should be noted that, in order to ensure relative independence of each application in the running process, processes of different applications may run in virtual machines that are isolated from each other. And thus, different processes cannot use resources (such as storage resources) in the virtual machines of other processes. Illustratively, process 1 may run in virtual machine 1, and may be able to use the storage resources provided by code cache 1. Process 2 may run in virtual machine 2 and may be able to use the storage resources provided by code cache 2. Due to the isolation of virtual machines 1, 2, process 1 cannot use the storage resources provided by code cache 2. Similarly, process 2 cannot use the storage resources provided by code cache 1.

It is to be understood that in a scenario where multiple applications are running simultaneously, different applications may perform JIT compilation on the same function and store the JIT compilation results repeatedly.

For example, when the application 1 runs, JIT compilation is performed on functions such as function 1 and function 2, and JIT compilation is also performed on functions such as function a and function B; the application 2 may perform JIT compilation on functions such as function 3, function 4, etc. while running, and may also perform JIT compilation on functions such as function a, function B, etc.

In conjunction with fig. 2B. Application 1 may store the machine code of function 1 in the code cache of application 1 after performing JIT compilation on function 1. Similarly, the machine code for function 2, function a, and function B may also be stored in the code cache of application 1. Similar to application 1, application 2 may also store machine code that executes the JIT compiled function in the code cache of application 2. For example, as shown in fig. 2B, the machine code of function 3, function 4, and function a and function B may be stored in the code cache of application 2. It can be seen that the machine code for function a and function B are stored 2 times in the code cache for application 1 and the code cache for application 2, respectively. Thus, the electronic device needs to repeatedly perform JIT compilation on the function a and the function B, and repeatedly store the machine code obtained by JIT compilation of the function a and the function B in different locations in the memory.

Similar to functions a and B, other functions that may be JIT compiled by multiple processes also suffer from the above-described problems of duplicate compilation and duplicate storage. This results in a rapid increase in code size and increased memory usage by code caches in various processes and increased CPU resources consumed to manage them. Which in turn accelerates the system into the end of performance. Namely, due to insufficient resources, the electronic device needs to constantly make room for new applications or programs. This adds further load pressure to the system.

In order to solve the foregoing problem, embodiments of the present application provide an application program running method, so that in a function running process, while maintaining relative independence between processes of respective applications, sharing of machine codes obtained by compiling is achieved. Therefore, the waste of computing resources and storage resources caused by repeated compiling and storage of the same function is avoided.

For example, please refer to fig. 2C in conjunction with fig. 2B. By adopting the scheme provided by the embodiment of the application, the shared code cache can be configured for the application 1 and the application 2 in the memory. The shared code cache may be used to store machine code (e.g., machine code for function a and function B) obtained by JIT compilation of functions that may need to be used while each application (e.g., application 1 and application 2) is running. Wherein the machine code of the function stored in the shared code cache may be obtained and stored by one of the plurality of applications via JIT compilation. In this way, repeated compilation of functions, as well as repeated storage, can be avoided.

The scheme provided by the embodiment of the application is described in detail below with reference to the accompanying drawings.

The electronic device according to the embodiment of the present application may be a portable mobile device such as a mobile phone, a tablet computer, a Personal Digital Assistant (PDA), an Augmented Reality (AR) \ Virtual Reality (VR) device, or a media player, and may also be a wearable electronic device such as a smart watch. The embodiment of the present application does not specifically limit the specific form of the apparatus.

Referring to fig. 3, a schematic structural diagram of an electronic device 300 according to an embodiment of the present disclosure is shown in fig. 3, where the electronic device 300 may include a processor 310, an external memory interface 320, an internal memory 321, a Universal Serial Bus (USB) interface 330, a charging management module 340, a power management module 341, a battery 342, an antenna 1, an antenna 2, a mobile communication module 350, a wireless communication module 360, an audio module 370, a speaker 370A, a receiver 370B, a microphone 370C, an earphone interface 370D, a sensor module 380, a button 390, a motor 391, an indicator 392, a camera 393, a display 394, and a Subscriber Identity Module (SIM) card interface 395. The sensor module 380 may include a pressure sensor, a gyroscope sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, and the like.

It is to be understood that the illustrated structure of the present embodiment does not constitute a specific limitation to the electronic device 300. In other embodiments, electronic device 300 may include more or fewer components than shown, or combine certain components, or split certain components, or a different arrangement of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

Processor 310 may include one or more processing units, such as: the processor 310 may include an Application Processor (AP), a modem processor, a Graphics Processing Unit (GPU), an Image Signal Processor (ISP), a controller, a memory, a video codec, a Digital Signal Processor (DSP), a baseband processor, and/or a neural-Network Processing Unit (NPU), etc. The different processing units may be separate devices or may be integrated into one or more processors 310.

The controller may be a neural center and a command center of the electronic device 300. The controller can generate an operation control signal according to the instruction operation code and the timing signal to complete the control of instruction fetching and instruction execution.

A memory may also be provided in the processor 310 for storing instructions and data. In some embodiments, the memory in the processor 310 is a cache memory. The memory may hold instructions or data that have just been used or recycled by the processor 310. If the processor 310 needs to reuse the instruction or data, it can be called directly from the memory. Avoiding repeated accesses reduces the latency of the processor 310, thereby increasing the efficiency of the system.

In some embodiments, processor 310 may include one or more interfaces. The interface may include an integrated circuit (I2C) interface, an integrated circuit built-in audio (I2S) interface, a Pulse Code Modulation (PCM) interface, a universal asynchronous receiver/transmitter (UART) interface, a mobile industry processor 310 interface (mobile industry processor interface, MIPI), a general-purpose input/output (GPIO) interface, a Subscriber Identity Module (SIM) interface, and/or a Universal Serial Bus (USB) interface, etc.

The electronic device 300 may implement a shooting function through the ISP, the camera 393, the video codec, the GPU, the display 394, the application processor, and the like.

The ISP is used to process the data fed back by the camera 393. For example, when a picture is taken, a shutter is opened, light is transmitted to a photosensitive element of the camera 393 through the lens, an optical signal is converted into an electric signal, and the photosensitive element of the camera 393 transmits the electric signal to the ISP for processing and converting the electric signal into an image visible to the naked eye. The ISP can also carry out algorithm optimization on the noise, brightness and skin color of the image. The ISP can also optimize parameters such as exposure, color temperature and the like of a shooting scene. In some embodiments, the ISP may be located in camera 393.

The camera 393 is used to capture still images or video. The object generates an optical image through the lens and projects the optical image to the photosensitive element. The photosensitive element may be a Charge Coupled Device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The light sensing element converts the optical signal into an electrical signal, which is then passed to the ISP where it is converted into a digital image signal. And the ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into image signal in standard RGB, YUV and other formats. In some embodiments, electronic device 300 may include 1 or more cameras 393.

The digital signal processor is used for processing digital signals, and can process digital image signals and other digital signals. For example, when the electronic device 300 selects a frequency bin, the digital signal processor is used to perform fourier transform or the like on the frequency bin energy.

Video codecs are used to compress or decompress digital video. The electronic device 300 may support one or more video codecs. In this way, the electronic device 300 may play or record video in a variety of encoding formats, such as: moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, and the like.

The NPU is a neural-network (NN) computing processor 310, which processes input information quickly by referring to a biological neural network structure, for example, by referring to a transfer mode between neurons of a human brain, and may also learn by itself continuously. The NPU can realize applications such as intelligent recognition of the electronic device 300, for example: image recognition, face recognition, speech recognition, text understanding, and the like.

The charging management module 340 is used to receive charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 340 may receive charging input from a wired charger via the USB interface 330. In some wireless charging embodiments, the charging management module 340 may receive a wireless charging input through a wireless charging coil of the electronic device 300. The charging management module 340 may also supply power to the electronic device 300 through the power management module 341 while charging the battery 342.

The power management module 341 is configured to connect the battery 342, the charging management module 340 and the processor 310. The power management module 341 receives input from the battery 342 and/or the charging management module 340 and provides power to the processor 310, the internal memory 321, the external memory, the display 394, the camera 393, and the wireless communication module 360. The power management module 341 may also be used to monitor parameters such as the capacity of the battery 342, the number of cycles of the battery 342, and the state of health (leakage, impedance) of the battery 342. In other embodiments, the power management module 341 may also be disposed in the processor 310. In other embodiments, the power management module 341 and the charging management module 340 may be disposed in the same device.

The wireless communication function of the electronic device 300 may be implemented by the antenna 1, the antenna 2, the mobile communication module 350, the wireless communication module 360, a modem processor, a baseband processor, and the like.

The antennas 1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in electronic device 300 may be used to cover a single or multiple communication bands. Different antennas can also be multiplexed to improve the utilization of the antennas. For example: the antenna 1 may be multiplexed as a diversity antenna of a wireless local area network. In other embodiments, the antenna may be used in conjunction with a tuning switch.

The mobile communication module 350 may provide a solution including 2G/3G/4G/5G wireless communication applied to the electronic device 300. The mobile communication module 350 may include at least one filter, a switch, a power amplifier, a Low Noise Amplifier (LNA), and the like. The mobile communication module 350 can receive electromagnetic waves from the antenna 1, filter and amplify the received electromagnetic waves, and transmit the electromagnetic waves to the modem for demodulation. The mobile communication module 350 may also amplify the signal modulated by the modem processor, and convert the signal into electromagnetic wave through the antenna 1 to radiate the electromagnetic wave. In some embodiments, at least some of the functional modules of the mobile communication module 350 may be disposed in the processor 310. In some embodiments, at least some of the functional modules of the mobile communication module 350 may be disposed in the same device as at least some of the modules of the processor 310.

The modem processor may include a modulator and a demodulator. The modulator is used for modulating a low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used for demodulating the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then passes the demodulated low frequency baseband signal to a baseband processor for processing. The low frequency baseband signal is processed by the baseband processor and then transferred to the application processor. The application processor outputs a sound signal through an audio device (not limited to the speaker 370A, the receiver 370B, etc.) or displays an image or video through the display screen 394. In some embodiments, the modem processor may be a stand-alone device. In other embodiments, the modem processor may be separate from the processor 310, and may be disposed in the same device as the mobile communication module 350 or other functional modules.

The wireless communication module 360 may provide solutions for wireless communication applied to the electronic device 300, including Wireless Local Area Networks (WLANs) (e.g., wireless fidelity (Wi-Fi) networks), bluetooth (BT), global Navigation Satellite System (GNSS), frequency Modulation (FM), near Field Communication (NFC), infrared (IR), and the like. The wireless communication module 360 may be one or more devices integrating at least one communication processing module. The wireless communication module 360 receives electromagnetic waves via the antenna 2, performs frequency modulation and filtering processing on electromagnetic wave signals, and transmits the processed signals to the processor 310. The wireless communication module 360 may also receive a signal to be transmitted from the processor 310, frequency-modulate and amplify the signal, and convert the signal into electromagnetic waves via the antenna 2 to radiate the electromagnetic waves.

In some embodiments, antenna 1 of electronic device 300 is coupled to mobile communication module 350 and antenna 2 is coupled to wireless communication module 360 such that electronic device 300 can communicate with networks and other devices through wireless communication techniques. The wireless communication technology may include global system for mobile communications (GSM), general Packet Radio Service (GPRS), code Division Multiple Access (CDMA), wideband Code Division Multiple Access (WCDMA), time division code division multiple access (time-division multiple access, TD-SCDMA), long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and/or IR technologies, etc. The GNSS may include a Global Positioning System (GPS), a global navigation satellite system (GLONASS), a beidou satellite navigation system (BDS), a quasi-zenith satellite system (QZSS), and/or a Satellite Based Augmentation System (SBAS).

The electronic device 300 implements display functionality via the GPU, the display screen 394, and the application processor, among other things. The GPU is an image processing microprocessor 310 connected to a display screen 394 and an application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 310 may include one or more GPUs that execute program instructions to generate or change display information.

The display screen 394 is used to display images, video, and the like. The display screen 394 includes a display panel. The display panel may adopt a Liquid Crystal Display (LCD) 394, an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (active-matrix organic light-emitting diode, AMOLED), a flexible light-emitting diode (FLED), a miniature, a Micro-oeld, a quantum dot light-emitting diode (QLED), and the like. In some embodiments, the electronic device 300 may include 1 or N display screens 394, N being a positive integer greater than 1.

The external memory interface 320 may be used to connect an external memory card, such as a Micro SD card, to extend the memory resources of the electronic device 300. The external memory card communicates with the processor 310 through the external memory interface 320 to implement a data storage function. For example, files such as music, video, etc. are saved in the external memory card.

The internal memory 321 may be used to store computer-executable program code, which includes instructions. The processor 310 executes various functional applications of the electronic device 300 and data processing by executing instructions stored in the internal memory 321. The internal memory 321 may include a program storage area and a data storage area. The storage program area may store an operating system, an application (such as a sound playing function, an image playing function, etc.) required by at least one function, and the like. The data storage area may store data created during use of the electronic device 300 (e.g., audio data, phone book, etc.), and the like. In addition, the internal memory 321 may include a high-speed random access memory, and may further include a nonvolatile memory, such as at least one magnetic disk storage device, a flash memory device, a universal flash memory (UFS), and the like.

The electronic device 300 may implement audio functions through the audio module 370, the speaker 370A, the receiver 370B, the microphone 370C, the earphone interface 370D, and the application processor. Such as music playing, recording, etc.

The audio module 370 is used to convert digital audio information into an analog audio signal output and also to convert an analog audio input into a digital audio signal. The audio module 370 may also be used to encode and decode audio signals. In some embodiments, the audio module 370 may be disposed in the processor 310, or some functional modules of the audio module 370 may be disposed in the processor 310.

The speaker 370A, also called "horn", is used to convert the audio electrical signal into a sound signal. The electronic device 300 may listen to music or to a hands-free conversation through the speaker 370A.

The receiver 370B, also called "earpiece", is used to convert the electrical audio signal into an acoustic signal. When the electronic device 300 receives a call or voice information, it is possible to receive voice by placing the receiver 370B close to the human ear.

Microphone 370C, also known as a "microphone," is used to convert the sound signal into an electrical signal. When a call is placed or a voice message is sent or it is desired to trigger the electronic device 300 to perform some function by the voice assistant, the user may speak via his/her mouth near the microphone 370C and input a voice signal into the microphone 370C. The electronic device 300 may be provided with at least one microphone 370C. In other embodiments, the electronic device 300 may be provided with two microphones 370C to achieve a noise reduction function in addition to collecting sound signals. In other embodiments, the electronic device 300 may further include three, four or more microphones 370C to collect sound signals, reduce noise, identify sound sources, and perform directional recording.

The earphone interface 370D is used to connect a wired earphone. The headset interface 370D may be the USB interface 330, or may be an open mobile electronic device 300 platform (OMTP) standard interface of 3.5mm, a cellular telecommunications industry association (cellular telecommunications industry association of the USA, CTIA) standard interface.

Touch sensors, also known as "touch panels". The touch sensor may be disposed on the display screen 394, and the touch sensor and the display screen 394 form a touch screen, which is also called a "touch screen". The touch sensor is used to detect a touch operation applied thereto or nearby. The touch sensor can communicate the detected touch operation to the application processor to determine the touch event type. In some embodiments, visual output related to touch operations may be provided through the display screen 394. In other embodiments, the touch sensor may be disposed on a surface of the electronic device 300 at a different location than the display screen 394.

The pressure sensor is used for sensing a pressure signal and converting the pressure signal into an electric signal. In some embodiments, the pressure sensor may be disposed on the display screen 394. There are many types of pressure sensors, such as resistive pressure sensors, inductive pressure sensors, capacitive pressure sensors, and the like. The capacitive pressure sensor may be a sensor comprising at least two parallel plates having an electrically conductive material. When a force acts on the pressure sensor, the capacitance between the electrodes changes. The electronic device 300 determines the intensity of the pressure from the change in capacitance. When a touch operation is applied to the display screen 394, the electronic apparatus 300 detects the intensity of the touch operation according to the pressure sensor. The electronic apparatus 300 may also calculate the touched position from the detection signal of the pressure sensor. In some embodiments, the touch operations that are applied to the same touch position but have different touch operation intensities may correspond to different operation instructions. For example: and when the touch operation with the touch operation intensity smaller than the first pressure threshold value acts on the short message application icon, executing an instruction for viewing the short message. And when the touch operation with the touch operation intensity larger than or equal to the first pressure threshold value acts on the short message application icon, executing an instruction of newly building the short message.

The gyro sensor may be used to determine the motion pose of the electronic device 300. In some embodiments, the angular velocity of the electronic device 300 about three axes (i.e., x, y, and z axes) may be determined by a gyroscope sensor. The gyro sensor can be used for shooting anti-shake. Illustratively, when the shutter is pressed, the gyroscope sensor detects the shake angle of the electronic device 300, calculates the distance that the lens module needs to compensate according to the shake angle, and enables the lens to counteract the shake of the electronic device 300 through reverse movement, thereby achieving anti-shake. The gyroscope sensor can also be used for navigation and motion sensing game scenes.

The air pressure sensor is used for measuring air pressure. In some embodiments, the electronic device 300 calculates altitude from barometric pressure values measured by a barometric pressure sensor, to assist in positioning and navigation.

The magnetic sensor includes a hall sensor. The electronic device 300 may detect the opening and closing of the flip holster using a magnetic sensor. In some embodiments, when the electronic device 300 is a flip phone, the electronic device 300 may detect the opening and closing of the flip based on the magnetic sensor. And then according to the opening and closing state of the leather sheath or the opening and closing state of the flip cover, the automatic unlocking of the flip cover is set.

The acceleration sensor may detect the magnitude of acceleration of the electronic device 300 in various directions (typically three axes). The magnitude and direction of gravity may be detected when the electronic device 300 is stationary. The method can also be used for identifying the posture of the electronic equipment 300, and is applied to horizontal and vertical screen switching, pedometers and other applications.

A distance sensor for measuring a distance. The electronic device 300 may measure the distance by infrared or laser. In some embodiments, taking a picture of a scene, the electronic device 300 may utilize a range sensor to range to achieve fast focus.

The proximity light sensor may include, for example, a Light Emitting Diode (LED) and a light detector, such as a photodiode. The light emitting diode may be an infrared light emitting diode. The electronic device 300 emits infrared light to the outside through the light emitting diode. The electronic device 300 detects infrared reflected light from a nearby object using a photodiode. When sufficient reflected light is detected, it can be determined that there is an object near the electronic device 300. When insufficient reflected light is detected, the electronic device 300 may determine that there are no objects near the electronic device 300. The electronic device 300 can utilize the proximity light sensor to detect that the user holds the electronic device 300 close to the ear for talking, so as to automatically turn off the screen to achieve the purpose of saving power. The proximity light sensor can also be used in a holster mode, a pocket mode automatically unlocks and locks the screen.

The ambient light sensor is used for sensing the ambient light brightness. The electronic device 300 may adaptively adjust the brightness of the display screen 394 based on the perceived ambient light level. The ambient light sensor can also be used to automatically adjust the white balance when taking a picture. The ambient light sensor may also cooperate with the proximity light sensor to detect whether the electronic device 300 is in a pocket to prevent inadvertent contact.

The fingerprint sensor is used for collecting fingerprints. The electronic device 300 may utilize the collected fingerprint characteristics to implement fingerprint unlocking, access an application lock, fingerprint photographing, fingerprint incoming call answering, and the like.

The temperature sensor is used for detecting temperature. In some embodiments, the electronic device 300 implements a temperature processing strategy using the temperature detected by the temperature sensor. For example, when the temperature reported by the temperature sensor exceeds the threshold, the electronic device 300 performs a reduction in performance of the processor 310 located near the temperature sensor, so as to reduce power consumption and implement thermal protection. In other embodiments, the electronic device 300 heats the battery 342 when the temperature is below another threshold to avoid the low temperature causing the electronic device 300 to shut down abnormally. In other embodiments, when the temperature is below a further threshold, the electronic device 300 performs a boost on the output voltage of the battery 342 to avoid an abnormal shutdown due to low temperature.

The bone conduction sensor may acquire a vibration signal. In some embodiments, the bone conduction transducer may acquire a vibration signal of the human voice vibrating a bone mass. The bone conduction sensor can also contact the pulse of the human body to receive the blood pressure pulsation signal. In some embodiments, the bone conduction sensor may also be disposed in a headset, integrated into a bone conduction headset. The audio module 370 may analyze a voice signal based on the vibration signal of the bone block vibrated by the sound part obtained by the bone conduction sensor, so as to implement a voice function. The application processor can analyze heart rate information based on the blood pressure beating signals acquired by the bone conduction sensor, and a heart rate detection function is realized.

Keys 390 include a power-on key, a volume key, etc. The keys 390 may be mechanical keys 390. Or may be touch keys 390. The electronic device 300 may receive key 390 inputs, generating key signal inputs related to user settings and function control of the electronic device 300.

The motor 391 may generate a vibration cue. The motor 391 may be used for both incoming call vibration prompting and touch vibration feedback. For example, touch operations applied to different applications (e.g., photographing, audio playing, etc.) may correspond to different vibration feedback effects. The motor 391 may also respond to different vibration feedback effects by performing touch operations on different areas of the display 394. Different application scenes (such as time reminding, receiving information, alarm clock, game and the like) can also correspond to different vibration feedback effects. The touch vibration feedback effect may also support customization.

Indicator 392 may be an indicator light that may be used to indicate a state of charge, a change in charge, or a message, missed call, notification, etc.

The SIM card interface 395 is for connecting a SIM card. The SIM card can be attached to and detached from the electronic device 300 by being inserted into and removed from the SIM card interface 395. The electronic device 300 may support 1 or N SIM card interfaces 395, N being a positive integer greater than 1. The SIM card interface 395 may support a Nano SIM card, a Micro SIM card, a SIM card, etc. Multiple cards can be inserted into the same SIM card interface 395 at the same time. The types of the plurality of cards may be the same or different. The SIM card interface 395 may also be compatible with different types of SIM cards. The SIM card interface 395 may also be compatible with external memory cards. The electronic device 300 interacts with the network through the SIM card to implement functions such as communication and data communication. In some embodiments, the electronic device 300 employs esims, namely: an embedded SIM card. The eSIM card can be embedded in the electronic device 300 and cannot be separated from the electronic device 300.

The application program running method provided by the embodiment of the present application can be applied to the electronic device 300 having the hardware composition shown in fig. 3. It should be noted that, in other embodiments of the present application, the hardware composition of the electronic device 300 may also be different from the example shown in fig. 3, for example, more components may be included in the electronic device 300, or the functions that can be supported in the electronic device 300 may be reduced to a part of the components shown in fig. 3 as needed.

In some embodiments, a software system may be run in the electronic device 300. The software system may employ a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. The following describes a software structure in the electronic device 300 by taking a software system in the electronic device 300 as an example of an android system having a hierarchical architecture.

The layered architecture provided by the embodiment of the application can divide software into a plurality of layers, and each layer has a clear role and division of labor. The layers communicate with each other through a software interface. As an example, please refer to fig. 4, which is a block diagram of a software structure of an electronic device according to an embodiment of the present application. In this example, the android system may include 3 software layers. From top to bottom are application 401, runtime (runtime) 402, and kernel 403, respectively.

In some embodiments, an application layer may also be included in the application 401, as well as an application framework layer.

Wherein the application layer may comprise a series of application packages. In some embodiments, the application package may include camera, gallery, calendar, phone call, map, navigation, WLAN, bluetooth, music, video, short message, etc. applications. The electronic device can implement corresponding functions by running the applications.

The application framework layer may provide an Application Programming Interface (API) and a programming framework for applications of the application layer. The application framework layer may also include some predefined functions.

In some examples, the application framework layer may include a window manager, a content provider, a view system, an explorer, a notification manager, an activity manager, an input manager, and the like.

The Window Manager provides a Window Management Service (WMS), and the WMS may be used for Window management, window animation management, surface management, and a transfer station as an input system. The content provider is used to store and retrieve data and make it accessible to applications. The data may include video, images, audio, calls made and answered, browsing history and bookmarks, phone books, etc. The view system includes visual controls such as controls to display text, controls to display pictures, and the like. The view system may be used to build applications. The display interface may be composed of one or more views. For example, the display interface including the short message notification icon may include a view for displaying text and a view for displaying pictures. The resource manager provides various resources for the application, such as localized strings, icons, pictures, layout files, video files, and so forth. The notification manager enables applications to display notification information in a status bar, can be used to convey notification-type messages, can disappear automatically after a brief dwell, and does not require user interaction. Such as a notification manager used to notify download completion, message alerts, etc. The notification manager may also be a notification that appears in the form of a chart or scroll bar text at the top status bar of the system, such as a notification of a background running application, or a notification that appears on the screen in the form of a dialog window. For example, prompting text information in the status bar, sounding a prompt tone, vibrating the electronic device, flashing an indicator light, etc. The Activity Manager may provide an Activity Manager Service (AMS), which may be used for the start-up, switching, scheduling of system components (e.g., activities, services, content providers, broadcast receivers), and the management and scheduling work of application processes. The Input Manager may provide an Input Manager Service (IMS), which may be used to manage inputs to the system, such as touch screen inputs, key inputs, sensor inputs, and the like. The IMS takes the event from the input device node and assigns the event to the appropriate window by interacting with the WMS.

The runtime 402 may provide a runtime environment for running programs in a current operating system, and there may be a plurality of different runtimes in different program languages and program frameworks in the same operating system or electronic device. In the android operating system, the runtime 402 can include an android runtime. For example, the runtime may include the virtual machine in the above description, and when the electronic device runs multiple applications simultaneously, a JAVA virtual machine may be created for each application. The android runtime can be used to convert java bytecode to machine code.

In some of the embodiments of the present application, the runtime may further include a core library.

The core library may be used to provide the functionality of the basic ART class library. Such as base data structures, mathematics, input/output (IO), tools, databases, networks, etc. libraries. The core library provides an API for android application development of users.

In some embodiments, the runtime 402 may also include language libraries such as native C/C + + libraries. A plurality of functional modules may be included. For example: surface manager (surface manager), media Framework (Media Framework), libc, openGL ES, SQLite, webkit, etc. Wherein the surface manager is configured to manage the display subsystem and provide a fusion of the 2D and 3D layers for the plurality of applications. The media framework supports playback and recording of a variety of commonly used audio and video formats, as well as still image files, and the like. The media library may support a variety of audio-video encoding formats, such as MPEG4, h.264, MP3, AAC, AMR, JPG, PNG, and the like. OpenGL ES provides for the rendering and manipulation of 2D graphics and 3D graphics in applications. SQLite provides a lightweight relational database for applications of electronic device 100.

The kernel 403 may be a layer between hardware and software. The kernel 403 at least includes a display driver, a camera driver, an audio driver, and a sensor driver. Through the drivers, the upper layer instructions can be converted into instructions which can be recognized and executed by corresponding hardware by the corresponding drivers. Thereby enabling a combination of software and hardware.

It should be noted that, in some embodiments of the present application, a hardware abstraction layer (not shown in fig. 4) may also be disposed between the runtime 402 and the kernel 403. The hardware is abstracted to run in user space (user space), encapsulates the kernel 403 driver, and provides a calling interface to the upper layer.

In addition, the software combination shown in fig. 4 is only one possible implementation and does not limit the solution provided in the embodiments of the present application, for example, in some embodiments, all or part of the runtime 402 may be integrated in the kernel 403, and all or part of the runtime 402 may also be integrated or packaged with the application.

As an example, the following describes an implementation of the running process of the function in connection with the software components shown in fig. 4. In this case, the electronic device calls the function M of the operating interpreted language as an example.

Refer to fig. 5A. The application in which the function M is located may be included in the application. When the function M of the application is executed, the runtime may read the function M from the application (i.e., perform S501). A series of processes may be performed on the function M in runtime. For example, in runtime, when executing the function M to the application, it may be determined whether the function M has been compiled (and S502 is executed). Wherein the compilation may be a JIT compilation. If the function M has already been compiled, then execution of the machine code may continue (e.g., execution S504). If the function M has not been compiled, the bytecode for executing the function M may be interpreted (e.g., execution S503). Correspondingly, if the function M has already been compiled, the machine code corresponding to the function M that has already been compiled in advance may be executed according to the logic shown by the implementation arrow (e.g., step S504). The function M is thus executed.

In some embodiments, the process of executing machine code may require the cooperation of hardware. In this example, the process of the electronic device running the function M may be performed by both runtime and kernel coordination. For example, in conjunction with fig. 5A, while the application is running, the kernel may allocate a process to run the application (e.g., perform S505). When the application is executed in the running process, the hardware can be driven by matching with the kernel.

In this example, the kernel may be further configured to allocate a process to the application, and may create a runtime environment for running the process in the process corresponding to the application, and a code cache for implementing fast reading and writing of data.

For example, taking the android system as an example, a zygate process may be configured in the android system, where the zygate process is a parent process of all the android processes, and other android processes (e.g., processes including a system service (system server) and various applications) may be obtained by being copied (or configured) through the zygate process. For example, the kernel may configure process 1 for application 1 via a zygate process. The kernel may initialize a corresponding runtime (referred to as runtime 1) in process 1 to execute the various functions of application 1 in the virtual machine runtime environment provided by runtime 1. In addition, the kernel can also configure a code cache 1 for the process 1, and the code cache 1 is used for storing data related to the process 1. Similarly, the electronic device may also configure process 2 for application 2. The kernel may initialize a corresponding runtime (referred to as runtime 2) in process 2 to execute the various functions of application 1 in the virtual machine runtime environment provided by runtime 2. In addition, the kernel may also configure a code cache 2 for process 2 for storing data related to process 2.

It should be noted that, in some embodiments, the zygate process may also have a corresponding storage space in the memory. The storage space may be used to store information common to different applications. It is understood that, taking the android system as an example, different applications may prompt for a new push message in the form of a corner mark. Then, the storage space of the zygate process may store the relevant configuration information of the corner mark, so that each application may inherit the relevant configuration information of the corner mark in the memory from the zygate process when copying and acquiring the corresponding process through the zygate process, thereby displaying the corner mark in the corresponding scene using the relevant configuration information of the corner mark.

As a possible implementation, the zygate process may map the storage addresses of various items of information (such as the relevant configuration information of the above-mentioned corner labels) in the storage space owned by the zygate process in the file descriptor of the zygate process. Therefore, when other applications copy and acquire respective corresponding processes through the zygate process, the file descriptor can be inherited, and information in the storage space of the zygate process can be acquired according to the information in the file descriptor.

In this embodiment, the storage space of the zygate process may further include address information that the shared code is cached in the memory. The shared code cached address in memory may be used to store machine code obtained by JIT compilation of functions that multiple applications need to use. For example, the address of the shared code cached in the memory may also be mapped in a file description where it is inherited by each application. Therefore, when different applications copy and acquire corresponding processes through the zygate process, the storage address of the shared code cache in the memory can be acquired through the file descriptor, and the storage address of the shared code cache is mapped to the virtual memory of the application process. It will be appreciated that since all application processes will inherit the address layout of zygate, they use the same start-up sequence and are based on process certainty. Thus, the shared code cache may be mapped to the same virtual address for each process. In some embodiments, the virtual address corresponding to the shared code cache may be obtained by the process in the form of a pointer, so that for different processes, the storage address corresponding to the shared code cache can be obtained by the pointer pointing to the virtual address corresponding to the shared code cache. Thereby enabling connection of the shared code cache to each virtual machine, and enabling each process to read data (e.g., JIT compilation results of functions) from the shared code cache. In some implementations, taking the operating system as Linux for example, the kernel can create a shared code cache through the shmget () function of the Linux itself. In other implementations, the kernel may create a shared code cache through an Ashem () function, taking the operating system as an android example.

For example, in conjunction with fig. 5B, both application 1 and application 2 may copy and acquire their corresponding processes (e.g., process 1 and process 2) through the zygate process. The process 1 and the process 2 may both be configured with respective corresponding private code caches in a memory, and are used to store data in the running process of each process. For example, the process 1 may be configured with a private code cache 1 in the memory, for storing the private code in the running process of the process 1 (i.e., the machine code obtained after JIT compilation of the function that only the process 1 will use). The process 2 may be configured with a private code cache 2 in the memory for storing the private code during the running process of the process 2 (i.e., the machine code obtained after JIT compilation of the function that only the process 2 will use).

The memory space in memory for process 1 and process 2 may also include a shared code cache. In conjunction with the foregoing description, since the storage addresses of the shared code cache are inherited from the file descriptor of the zygate process, the shared code caches of the process 1 and the process 2 may have the same virtual address. Therefore, taking the example that the function M is called by multiple applications, after the application 1 obtains the corresponding machine code after JIT compiling the function M, the JIT compiled machine code of the function M can be stored in the shared code cache of the process 1. Having the same virtual address, the JIT-compiled machine code for function M can also be found in the shared code cache of process 2 when application 2 calls function M. So that application 2 can directly call the JIT compiled machine code of function M. Thereby enabling sharing of the JIT-compiled machine code of the function M, i.e., avoiding duplicate compilation and storage of the function M.

It should be noted that, because all the application processes are obtained by copying from the zygate process, that is, all the application processes can configure the shared code cache having the same virtual address in their respective processes by integrating the file descriptor of the zygate process. Thus, the data in the shared code cache can be used for all applications running in the electronic device.

In conjunction with the above description, after the function triggers JIT compilation, the JIT compiled machine code may be stored via a memory resource provided by a private code cache allocated by the kernel for the process running the function, and/or a shared code cache. So as to use the machine code for efficient operation when the function is executed in a subsequent call.

It should be noted that, in some embodiments of the present application, the shared code cache configured by the kernel may include a series of sub-caches that are continuous and have the same size. These sub-caches may be under the control of the processes of the respective applications. Therefore, the processes of the applications can maintain the data in the corresponding sub-caches, and the electronic equipment can maintain the shared code cache.

For example, in some embodiments, a process that maintains a sub-cache may be referred to as an owner process (owner process) for the sub-cache. The owner process may write data to the corresponding sub-cache. For example, the owner process may write the machine code obtained via JIT compilation into a maintained sub-cache. For other processes, i.e., non-owner processes, the machine code can only be read and executed from the sub-cache. Thus, by assigning one owner process to each sub-cache and restricting access rights of other processes. The read-write conflict and the write-write conflict which may occur in the process of reading and writing data in the shared code cache can be avoided. In addition, the attack of security holes with bottom access authority on the memory can be reduced.

In addition, in other embodiments of the present application, the accuracy of the global shared mapping may also be protected by setting a semaphore (semaphore). For example, when process 1 is reading a function M to share machine code M in a shared code cache, process 2 is updating the shared machine code M. It can be seen that in this scenario, both process 1 and process 2 have control requirements for data in the shared code cache (e.g., shared machine code M). Then, in this example, in order to avoid that the shared machine code M read by the process 1 is not the latest updated machine code, the process 1 may return to the interpretation execution if there is another process (e.g., the process 2) updating the shared machine code M when the shared machine code M needs to be read, or call the shared machine code after the process 2 completes the update of the shared machine code M. That is, the process reading the machine code has a lower execution priority than the process updating the machine code. Therefore, the logic sequence which is updated and then read can be ensured, and the accuracy of the read machine code is ensured.

The following describes in detail a specific implementation process of the solution provided by the embodiments of the present application with reference to the accompanying drawings.

Fig. 6 is a schematic flowchart of an application running method according to an embodiment of the present application. Taking the operation function M as an example. As shown in fig. 6, the method may include:

s601, starting.

In some embodiments of the present application, the flow shown in fig. 6 may be started (i.e., started) when the electronic device loads and executes the application. With reference to the above description, after the electronic device loads and executes an application, the electronic device may create a corresponding process for the application. Based on the process, the electronic device can enable loading and execution of the application.

The electronic device may also configure a private code cache for a process of an application when the application is loaded and executed, and a shared code cache that is accessible to all applications. For example, in some embodiments, when creating a process of an application, the electronic device may allocate a storage space (i.e., a private code cache corresponding to the application) in a memory for storing data (e.g., private code shown in fig. 2B) during the running process of the application. In other embodiments, when the electronic device runs the application program for the first time after starting, a section of storage space may be allocated in the memory to implement configuration of the shared code cache for storing the system shared code. Based on the foregoing description, the shared code cache is a part of the storage space in the memory that can be accessed by each application program.

S602, when the function M of the application is executed, whether the function M is compiled or not is judged.

For example, the electronic device may read the bytecode of the function M when executing the function M in the process of the application, and since a JIT compiling mechanism is introduced, the bytecode of the function M may have been subjected to JIT compiling to obtain machine code when executing the function M. Of course, the bytecode of the function M may not have triggered JIT compilation yet.

In some embodiments of the present application, the electronic device may determine whether the function M has been JIT compiled by way of pointer lookup. The pointer may be a pointer used for storing a storage address of the machine code obtained after the function M is subjected to JIT compilation, in a data structure corresponding to a function signature (e.g., a function name) of the function M. For example, the electronic apparatus may determine whether or not the function M has been JIT-compiled by determining whether or not an address pointer for pointing to a result of JIT-compiling the function M in correspondence with the function M is empty, or determining whether or not a pointer to a machine code of the function M included in metadata in correspondence with the function M is empty when the function M is called. When the address pointer is empty, it indicates that the memory address for storing the function M does not store the machine code, and thus indicates that the JIT compilation has not been performed on the function M; when the address pointer is not empty, it indicates that the memory address for storing the function M stores machine code, and thus indicates that JIT compilation has been performed on the function M.

In another possible implementation, when the function is in the form of a function name (e.g., embodied in the form of a character string), the electronic device may search for and acquire an array member corresponding to the function by performing hash processing on the function name. If the information of the function M maintained in the data structure pointed to in the array member includes a pointer to the machine code of the function M in the information of the function M maintained, then the function M may be considered to have been JIT compiled. Correspondingly, when the maintained information of the function M does not include the pointer to the machine code of the function M, or the pointer to the machine code of the function M is invalid, or the pointer to the machine code of the function M is null, the function M may be considered as not JIT-compiled.

It should be noted that, in the embodiment of the present application, if a developer recognizes in advance or the electronic device recognizes that the function M may be called by the processes of a plurality of applications, the JIT compilation result of the function M may be stored in the shared code cache. When the developer recognizes in advance or the electronic device recognizes that the function M is to be called only by the current process, the JIT compilation result of the function M may be stored in the private code cache of the current process. Therefore, in the embodiment of the present application, when the electronic device executes S502, the electronic device may search for the JIT compilation result of the function M in the private code cache and the shared code cache, respectively.

In this example, in the case where the function M has been compiled, the electronic device may perform S604. In the case where the function M has not been compiled, S603 is executed.

And S603, explaining the byte codes of the execution function M.

For example, the electronic device may translate the bytecode of the function M line by line through the interpreter to obtain the machine code corresponding to the line. In some embodiments, the electronic device may complete the translation of a row of bytecode each time, i.e., begin executing machine code corresponding to the row of bytecode. Then, the next row of bytecode translation is performed, and so on, the interpretation execution of all bytecodes in the function M is completed. In other embodiments of the present application, the interpretation and execution by the electronic device may be performed in parallel as an example. After the electronic device completes the translation of a row of bytecodes in the function M, the electronic device executes the machine code corresponding to the row of bytecodes. Meanwhile, the electronic device can also translate the next row of bytecodes in the function M during the execution of the machine code.

S604, executing the machine code which corresponds to the function M and is compiled in advance.

In this example, the electronic device may execute the S504 when it is determined that the function M has been compiled, that is, read the machine code obtained after JIT compiling the function M from the memory, and execute the machine code, thereby implementing the running of the function M.

Illustratively, in some embodiments, the function M is in the form of a pointer. The electronic device may read the machine code of the function M from the data structure pointed to by the pointer, from the memory address pointed to by the pointer of the machine code of the function M included in the maintained information of the function M.

In some embodiments of the present application, the function M is not called by other processes. The compiled machine code for function M may be stored in the private code cache of the current process. Then, when S604 is executed, the electronic device may obtain the machine code of the function M from the private code cache according to the method in the above example and execute the function M.

In other embodiments of the present application, the function M may be called by other processes. In conjunction with fig. 2B, the machine code obtained after the function M is compiled may be stored in the shared code cache as system shared code. Then, when this S604 is executed, the electronic device may obtain the compiled machine code of the function M from the shared code cache and execute it according to the method in the above example.

It should be noted that, in other embodiments of the present application, when the function M is called by multiple processes, the compiled machine code of the function M may be stored in both the private code cache and the shared code cache. It is understood that the machine code of the function M stored in the private code cache may be obtained by compiling the machine code by using optimization means such as inlining. Therefore, when the machine code runs in a virtual machine of the current process, the running efficiency of the machine code can be higher than that of the machine code obtained by compiling the optimization means such as unused inlining and the like stored in the shared code cache. Therefore, when this S604 is executed, the electronic device may obtain the machine code of the function M from the private code cache according to the method in the above example and execute the function M.

S605, judging whether the explaining times reach the sharing JIT threshold value.

In this example, the electronic device may determine whether to trigger JIT compilation of the function M according to the number of interpretations of the function M. Wherein the shared JIT threshold may be a default shared threshold preset in the ART virtual machine. The default shared threshold may be a shared JIT threshold that is common to all functions. That is, in this example, for any function in any application, it may be determined whether to trigger JIT compilation of the function M according to the default sharing threshold.

In other embodiments of the present application, different shared JIT thresholds may also be set for different functions.

For example, in some implementations, functions may be divided into classes a and B. A function of class a may have one shared JIT threshold and a function of class B may have another shared JIT threshold. In some embodiments, the function of class A may be a function called during application launch. The class B function may then be a function that needs to be called after the start-up procedure is completed.

In other embodiments of the present application, a JIT threshold record file (e.g., referred to as a shared JIT threshold record file) may also be configured in the electronic device. In the JIT threshold value recording file, a shared JIT threshold value corresponding to each function may be stored. Then, the electronic apparatus may call the shared JIT threshold corresponding to a different function in the shared JIT threshold log file before executing S605, and determine whether the number of interpretations of the current function M reaches the shared JIT threshold according to the shared JIT threshold corresponding to the function M. In some implementations, the shared JIT threshold in the shared JIT threshold log file may be adaptively adjusted by the electronic device based on the performance of the function.

Taking the example of configuring the shared JIT threshold value log file in the electronic device, the current process (e.g., process 1) may read the corresponding relationship between different functions and the respective corresponding shared JIT threshold values from the shared JIT threshold value log file and store the corresponding relationship in the memory before S605 is executed. Process 1 may determine the shared JIT threshold for function M by looking up the data structure when executing S605. For example, the process 1 may use the function signature of the function M as a key value to search a hash table in a memory of the electronic device, where the hash table stores a shared JIT threshold corresponding to each function, and the value of the output obtained thereby may be the shared JIT threshold corresponding to the function M. Based on the shared JIT threshold and the current number of interpretations of the function M, the electronic device can determine whether the number of interpretations reaches the JIT threshold.

It should be noted that, in some embodiments of the present application, before looking up the hash table, the electronic device may traverse key values in the hash table, so as to determine whether a key value corresponding to the function signature of the function M exists. If the hash table exists, the compiling threshold corresponding to the function M exists in the hash table. If not, the electronic device can employ a default shared threshold as the shared JIT threshold for function M.

S606, judging whether the function M is called by other processes.

It is to be appreciated that in the case where the number of interpretations of the function M reaches the shared JIT threshold, the electronic device can determine whether the function M is a shared function according to whether the function M has been called by other applications. In the embodiment of the present application, the shared function may refer to a function that may be called by two or more applications. For a shared function, after the function is compiled in a process of an application, since other processes also have the need to call the function, the compilation result of the function can be stored in a shared code cache.

It should be noted that, in some embodiments of the present application, the call of the function by the application may refer to a call made after the application process performs JIT compilation on the function. For example, take the case where process 1 executes step S606. After the process 2 JIT-compiles the function M, if the function M is also called, the process 1 may consider that the process 2 called the function M. In this case, the determination result of S606 may be yes.

In some embodiments of the present application, a currently applied process (e.g., process 1) may determine whether the function M has been called by another process according to the global function access record table. The global function access record table may be stored in a non-volatile storage medium connected through the external memory interface 320 in the electronic device 300 shown in fig. 3, or may be stored in the shared code cache. The global function access record table may indicate the calling condition of different functions by different processes. For example, when the process 1 calls the function M, an access record table (e.g., referred to as an access record table M) corresponding to the function M may be established in the shared code cache. After the process 1 JIT compiles the function M, 1 call record may be added to the access record table M every 1 call of the function M. Thus, when the process 2 calls the function M, it can be determined that the function M was called by the process 1 by reading the access record table M.

As an example, table 1 shows an illustration of an access record table M corresponding to a function M.

TABLE 1

In the example of Table 1, it can be seen that function M is called 3 times by process 1, 5 times by process 2, and so on. That is, when there is another process different from the current process in the access log M, it can be determined that the function M has been called by the other process. It should be noted that, taking a currently running process as the process 1 as an example. If the function M has not been called by other processes, the access record table M may be empty, or the access record table M may not be created in the shared code cache, or only the call information of the process 1 in the access record table M. At this point, process 1 may determine that function M has not been called by other processes.

It is understood that when a plurality of functions are called by a plurality of different processes, the global function access record table may include an access record table corresponding to each of the plurality of functions as shown in fig. 7. For example, the global function access record table may include access record table 1, access record table 2, \8230;, access record table M, \8230;, access record table N, as shown in fig. 7. Wherein N is an integer greater than M. In the embodiment of the present application, each access record table in the global function access record table may have the call information as shown in table 1. Therefore, the current process (such as the process 1) can search the corresponding access record table from the global function access record table according to the pointer corresponding to the function signature of the function with judgment (such as the function M), and further determine whether the function is called by other processes (such as processes except the process 1) according to the calling information in the access record table.

S607, the function M is subjected to shared JIT compilation.

When the function M is called by at least 2 processes at the same time, if the function M is triggered to JIT compilation, the electronic device can perform shared JIT compilation on the function M.

Illustratively, take the current process as process 1 as an example. Process 1 may share JIT compilation of function M by initiating a JIT compilation thread. In this example, the function M may be invoked by a process in a different virtual machine due to its shared JIT compilation result. Therefore, in some embodiments, process 1 may not be able to process the compilation result of function M using inlining or the like optimization when performing shared JIT compilation on function M. In this way, although the performance of the machine code of the function M obtained after performing the shared JIT compilation may be weaker than the compilation result obtained by processing the machine code of the function M in an optimization manner such as inline, it is thereby ensured that an access address error and other problems occur when different processes perform shared code cache access with respect to the same function (e.g., the function M), thereby ensuring the sharing of the machine code of the function M.

In some implementations of the present application, the shared JIT compilation may be implemented by a separate process. For example, a process 1 of the application 1 is taken as an example of a process currently calling the function M. As shown in fig. 6, the process 1 may implement operations such as interpreting and executing the function M by interpreting a thread. For example, the explain thread of process 1 may implement S601-S604 as shown in FIG. 6. Since the shared JIT compilation may be invoked during different process transactions, the electronic device may create a shared JIT compilation process via a zygate process for performing the shared JIT compilation. For example, referring to fig. 6, the shared JIT compilation process shown in S605-S608 may be implemented in a shared JIT compilation process.

It should be noted that the processing mechanism shown in fig. 6 is only an example. In other embodiments of the present application, the explain thread of process 1 may be used to implement S601-S606. When it is determined in S606 that the function M is out of date by other processes, the interpretation thread may notify the shared JIT compilation process to perform shared JIT compilation on the function M, i.e., perform S607-S608.

And S608, storing the acquired JIT compiling result in a shared code cache.

In this example, the current process (e.g., process 1) may store the compilation results of the shared JIT compiled function M (e.g., referred to as the shared machine code M) in a shared code cache.

It will be appreciated that after the shared machine code M is stored in the shared code cache, it may be invoked by multiple processes, including the current process (e.g., process 1). In order to realize effective access of each process in different virtual machines to machine codes stored in a shared code cache, in the embodiment of the present application, a function state record table may be configured in an electronic device. According to the function state record table, processes in different virtual machines can call function signatures of functions according to current needs, and machine codes of corresponding functions after shared JIT compiling are searched in a shared code cache.

Illustratively, table 2 is an illustration of a function state record table.

TABLE 2

Function name (APP name)	Index (index)
		Function signature 1	Address 1
Function signature 2	Address 2
		……	……

As shown in table 2, in the function state record table, the function signatures of different functions and the storage addresses of the machine codes of the functions after the functions are subjected to the shared JIT compilation in the shared code cache may be stored. For example, the storage address in the shared code cache for the function 1 corresponding to the function signature 1 may be address 1. Then when the process calls the function 1, the shared machine code 1 corresponding to the function 1 can be obtained from the address 1, so that the operation of the function 1 can be completed by executing the shared machine code 1. Similarly, the function signature 2 corresponds to the function 2, and the storage address in the shared code cache may be the address 2. Then when the process calls the function 2, the shared machine code 2 corresponding to the function 2 can be obtained from the address 2, so that the function 2 can be executed by executing the shared machine code 2.

In the function state record table shown in table 2, the function name is identified by a function signature (i.e., a character string corresponding to the function name) as an example. In other embodiments of the present application, the function name may also be identified by other parameters, for example, by the entry parameters of the function.

In this example, the compiling result corresponding to no function M in the function state record table is taken as an example. After the current process (e.g., process 1) acquires the shared machine code M in S607, process 1 may create an entry corresponding to the function M in the function state record table shown in table 2. Process 1 may also store the machine code of function M at a corresponding address (e.g., address M). Illustratively, the table of function state records after adding the entry corresponding to the function M is shown in table 3.

TABLE 3

Function name (APP name)	Index (index)
		Function signature 1	Address 1
Function signature 2	Address 2
		……	……
Function signature M	Address M
		……	……

According to table 3, when another process (e.g., process 2) needs to call the machine code of the function M, the shared machine code M corresponding to the function M can be obtained from the address M according to table 3, so that the function M can be executed by executing the shared machine code M.

It should be noted that, in other embodiments of the present application, in the function state record table, the address indicated by the index may also be determined by the base address and the offset. For example, table 4 shows an illustration of yet another function state record table.

TABLE 4

Function name	Base address	Offset (offset)
			Function signature 1	Base site 1	Offset 1
Function signature 2	Base site 2	Offset 2
			……	……	……
Function signature M	Base address M	Offset M
			……	……	……

The storage address of the shared machine code of the function in the shared code cache can be determined by the base address and the offset. For example, the shared machine code 1 of the function 1 corresponding to the function signature 1 may have a storage address in the shared code cache of base address 1+ offset 1. Similar function signature 2 corresponds to shared machine code 2 of function 2, and the storage address in the shared code cache may be base address 2+ offset 2. Similar function signature M corresponds to shared machine code M of function M, and the storage address in the shared code cache may be base address M + offset M.

Through the above description of the scheme shown in fig. 6, the current process may store the machine code of the function that meets the requirement in the shared code cache through the judgment of S605 and S606. The current process may also update the invocation information of the machine code for the function into a function state record table as shown in table 2 or table 3 or table 4. Therefore, when other processes need to call the function, the machine code of the function can be found from the shared code cache according to the function state record table, and the machine code is called and executed. Thereby avoiding the computational power waste introduced by repeated JIT compilation of the same function and the waste of memory resources introduced by repeated storage of machine code.

It can be understood that, for the machine code in the shared code cache, since it is necessary to ensure that processes in different virtual machines can be smoothly accessed, when the function is subjected to shared JIT compilation, the machine code of the function cannot be optimized by optimization means such as inlining. That is, for some shared functions, the performance of the shared machine code that it stores in the shared code cache is not optimal for a portion of the virtual machine. In order to further improve the running efficiency of the function in the process, in other embodiments of the application, the electronic device may further perform private JIT compilation on the function with a higher calling frequency in the current process based on the scheme shown in fig. 6. For example, optimization means such as an inlining is adopted to optimize machine codes of a function meeting requirements, and the machine codes (for example, called as private machine codes) are stored in a private code cache corresponding to a current process, so that when the function is called again in a subsequent process, the private machine codes meeting the current virtual machine running environment better can be obtained from the private code cache, and thus the running efficiency of the function is improved.

For example, please refer to fig. 8, which is a flowchart illustrating a method for running another application according to an embodiment of the present application. In this example, the current process (e.g., process 1) may add steps S801 to S803 on the basis of the execution method of the application program according to the scheme shown in fig. 6, so as to achieve the effect of optimizing the operating efficiency of the function. To be able to explain the scheme of the present example in detail, the following takes as an example the shared JIT threshold as P, the private JIT threshold as Q, Q being an integer greater than P. It is to be understood that since the shared JIT threshold P is less than the private JIT threshold Q, in the case where the number of calls to the function M in the process 1 is greater than Q, the shared JIT compilation of the function M is triggered first, and then the private JIT compilation of the function M is started.

In this example, the electronic device may perform the execution of the function M in accordance with the scheme shown as S602-S608 before performing the shared JIT compilation of the function M. After sharing the JIT for the function M, the electronic apparatus may continue to call the function M in the process 1, and may continue to execute the execution of the function M according to the scheme shown in S801 to S805.

It should be noted that, in the scheme shown in fig. 8, the execution manner and description of S601-S608 may refer to the above description of the scheme shown in fig. 6, and are not repeated here.

The following describes the operation mechanism of the function M being called more than P times (e.g., Q times). As shown in fig. 8, the scheme may include:

s801, when the function M of the application is executed, judging whether the function M is compiled or not.

The step can be executed by referring to the description of S602 in fig. 6, which is not described herein again.

S802, executing the machine code which corresponds to the function M and is compiled in advance.

It will be appreciated that this is because at the P-th call, shared JIT compilation of the function M has already been triggered. Therefore, in this example, the process 1 can determine that the function M has been compiled from the function state record table when performing the determination of S801. The process 1 can call and execute the shared machine code M corresponding to the function M according to the function state record table. That is, in this example, the machine code compiled in advance may be shared machine code M stored in a shared code cache.

S803, it is determined whether the number of calls reaches the private JIT threshold.

In this example, the electronic device may obtain the private JIT threshold corresponding to the function M when it needs to determine whether the number of calls reaches the private JIT threshold.

It will be appreciated that, similar to the setting of the shared JIT threshold, the electronic device may obtain the private JIT threshold for the function M in a number of different ways.

For example, the private JIT threshold for function M may be a default private threshold stored in the ATR virtual machine. As another example, the private JIT threshold for function M may be a private JIT threshold for a class (e.g., class a or class B) corresponding to function M. As another example, the private JIT threshold for the function M may also be obtained from a private JIT threshold log file. The private JIT threshold recording file may store therein the private JIT thresholds corresponding to the different functions, respectively. In some implementations, the respective private JIT thresholds for the different functions may be adaptively adjusted by the electronic device according to the behavior of the function in the application.

Taking the example of configuring the JIT threshold recording file in the electronic device, the process 1 may obtain the private JIT threshold corresponding to the function M through a hash algorithm or the like according to the data structure of the function M.

In this way, the electronic device can determine, via process 1, whether the number of calls reaches the private JIT threshold in conjunction with the number of calls of the current function M.

And S804, carrying out private JIT compiling on the function M.

The way the electronic device performs private JIT compilation on the function M may refer to the description of S203 shown in fig. 2A.

S805, the obtained private JIT compilation result is stored in a private code cache.

In this example, the private JIT compilation result obtained by the electronic device through the process 1 performing the private JIT compilation on the function M may be a result of performing optimized compilation on the function M in an inline manner or the like.

In conjunction with the foregoing description of S608, the electronic device may store the shared JIT compilation result in the function state record table. In this example, the function record table used to store the shared JIT compilation results may be referred to as a shared function state record table. It will be appreciated that the shared function state record table may be stored in a shared code cache for use by various processes. In this example, the electronic device can also configure a corresponding private function-state record table for the private JIT compilation result. The private function state record table may be stored in a private code cache (e.g., private code cache 1 of process 1). In some embodiments, the private-state record table may also have a form as shown in table 2 or table 3 or table 4, storing the correspondence of the respective functions with the storage addresses of the private machine code acquired after the private JIT compilation. In this way, in the running process after the process 1, if the function M needs to be called again, the storage location of the private machine code M corresponding to the function M in the private code cache 1 can be obtained according to the private-state record table. And then the private machine code M is obtained from the storage position and executed, thereby realizing better operation effect compared with the execution according to the shared machine code M.

The description of fig. 6 is combined with the above description. The process of interpreting execution may be implemented by an interpretation thread in a process (e.g., process 1) that calls function M. The process of shared JIT compilation may be implemented in a shared JIT compilation process. In the private JIT compilation as shown in fig. 8, however, since the private JIT compilation result is called again only by the process 1, the private JIT compilation may be performed in the virtual machine environment of the process 1. That is, in some embodiments, this private JIT compilation process may be implemented by a JIT compilation thread created in Process 1.

It can be understood that, through the above description of fig. 6 and fig. 8, after the process 1 completes P runs of the function M, the private machine code M may be stored in the private code cache 1 of the process 1. The shared code cache may store the shared machine code M. Then, on this basis, when the electronic device executes S602 shown in fig. 6 or fig. 8, it may determine whether the function M is compiled according to whether the machine code corresponding to the function M is stored in the private code cache and the shared code cache.

It is noted that in some embodiments of the subject application, the electronic device may preferentially compile the acquired machine code stored in the private code cache using the private JIT and, if the acquired machine code does not exist, compile the acquired machine code stored in the shared code cache using the shared JIT.

Illustratively, the function M is taken as an example. In some embodiments of the present application, the electronic device may determine whether the private machine code M exists in combination with the private function state record table in the foregoing description.

For example, the electronic device may perform the hash calculation according to the function name of the function M (e.g., a function signature, or an argument of the function M). The object of the hash computation may be a private function state record table. For example, the electronic device may search for a matching item of the function M in the function name in the private function-state record table through a hash algorithm. If so, it indicates that process 1 has created an entry of the private machine code M corresponding to the function M in the private function state record table. It will be appreciated that process 1 may create an entry in the private function-state record table corresponding to function M when triggering the private JIT compilation of function M. Thus, if an entry corresponding to the function M exists in the determined private function-state table, it can be determined that the function M has been compiled by the private JIT. The electronic device can then execute the pre-compiled machine code M corresponding to the function M. Conversely, if no entry corresponding to the function M is found in the private function-state record table, this indicates that process 1 has not yet performed private JIT compilation of the function M. The electronic device can then determine whether the function M is subject to shared JIT compilation. Similarly, the electronic device may determine, through a hash algorithm, whether an entry matching the function M exists in the shared function state record table. If so, then the shared JIT compilation has been performed on the function M by other processes. The electronic device may then execute the pre-compiled shared machine code M corresponding to the function M. If not, this indicates that the function M has not been shared JIT compiled. The electronic device may then execute S603, i.e. interpret the bytecode for executing the function M.

In this way, the electronic device can preferentially select the machine code execution function obtained by the private JIT compilation, so that the execution of the function can be more matched with the execution environment provided by the current virtual machine, and the execution efficiency of the function is improved.

As the application runs, there will be continuous storage of machine code after the shared JIT compilation and the private JIT compilation in the memory of the electronic device. Therefore, the embodiment of the application also provides a garbage processing mechanism of the shared code cache and the private code cache, so that the machine codes in the shared code cache and the private code cache are always in the latest state, and meanwhile, the waste data in the shared code cache and the private code cache can be efficiently processed, so that the corresponding storage resources are released.

For example, the electronic device may perform garbage collection on the shared code cache and the private code cache according to a load condition of the memory. The load condition of the memory may include states of abundant memory, light memory load, and heavy memory load. As a possible implementation, when the usage rate of the memory of the electronic device is lower than the first threshold, the electronic device may consider the memory to be abundant. When the usage rate of the memory of the electronic device is higher than the first threshold and lower than the second threshold, the memory may be considered to be lightly loaded. And when the utilization rate of the memory is higher than a second threshold value, the memory is considered to be overloaded.

In some embodiments of the present example, the electronic device may perform shared garbage collection or private garbage collection depending on the load condition. Shared garbage collection can be used for collecting the shared machine code which is not called by the process and stored in the shared code cache. Private garbage collection may be used to collect shared code cache that, although called, does not call the shared machine code for which the number of calls has reached the private JIT compilation threshold.

In some embodiments, the electronic device may not perform garbage collection with sufficient memory. As one possible implementation, the electronic device may detect the number of calls of the shared machine code with abundant memory. For example, the electronic device may add a data structure to the shared function state record table (e.g., table 2, or table 3, or table 4 above) that indicates the number of calls to the shared machine code for the function. Illustratively, table 5 shows an illustration of a shared function state record table. In the example, the storage address of the shared machine code is identified by the base address and the offset in the shared function state record table.

TABLE 5

Function name	Base address	Offset (offset)	Number of calls
				Function signature 1	Base site 1	Offset 1	1
Function signature 2	Base site 2	Offset 2	3
				……	……	……	……
Function signature M	Base address M	Offset M	4
				……	……	……	……

As shown in table 5, the electronic device can know the calling status of each function in the shared code cache through the shared function status record table. As one possible implementation, the process may update the number of calls when calling the shared machine code of a function using the shared function state record table. For example, function 1 may update the number of calls plus 1 in the entry corresponding to function 1 (e.g., the entry in the row where function signature 1 is located) when the shared machine code of function 1 is called through the shared function state record table shown in table 5. Thus, the purpose of detecting the number of calls of the shared machine code can be realized through the shared function state recording table. For example, through table 5, the electronic device may know that function 1 is called 1 time, function 2 is called 3 times, function M is called 4 times, and so on.

The electronic device can trigger the shared garbage recycling strategy when the memory is lightly loaded. For example, the electronic device may perform garbage collection processing on the shared machine code corresponding to the function with the call frequency of 0 in the shared function state record table, thereby releasing the storage resource in the corresponding shared code cache.

The electronic device can trigger the private garbage collection strategy when the memory is overloaded. For example, the electronic device may perform garbage collection on the shared machine code in the shared function state record table, where the number of calls does not reach the private JIT compilation threshold of the corresponding function, thereby further releasing the storage resource in the corresponding shared code cache.

In some embodiments of the present application, in the process of executing the shared garbage collection policy or the private garbage collection policy, the electronic device may select, according to the number of calls of each shared machine code, an order of machine codes for executing the garbage collection policy. For example, in combination with table 5, when the memory of the electronic device enters the reloading state, garbage collection may be performed on the shared machine codes sequentially according to the order of the number of calls from small to large. For example, the electronic device may perform garbage collection according to the order of function 1, function M, and function 2. Of course, in the process of executing garbage collection, if the load of the memory is changed from heavy load to light load, the private garbage collection policy can be stopped. For example, after the garbage collection corresponding to the function 1 is completed, the memory load becomes light, and then the garbage collection for the function M may be stopped. And executing the corresponding shared garbage recycling strategy on other shared machine codes which are not called. It should be noted that after execution, because the state of the shared machine code in the shared code cache changes, for example, the shared machine code that is performed garbage collection cannot be called again by other processes. Therefore, in some embodiments of the present application, the electronic device may adjust corresponding entries of the global access record table and the shared function state record table while performing garbage collection, so as to ensure accuracy of the entries. For example, after performing garbage collection on the shared machine code M of the function M, the electronic device may delete the entry corresponding to the function M from the shared function record table, so as to avoid a situation that another process misinvokes the shared machine code M.

It is to be understood that, in the above example, garbage collection is performed on the shared code cache as an example. In other embodiments of the present application, the electronic device may further perform garbage collection on the private code cache by referring to the garbage collection policy for the shared code cache. Therefore, garbage collection of the shared code cache and the private code cache is realized, and further, the memory load can be regulated and controlled within a reasonable range.

The scheme provided by the embodiment of the application is mainly introduced from the perspective of electronic equipment. To implement the above functions, it includes hardware structures and/or software modules for performing the respective functions. Those of skill in the art would readily appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as hardware or combinations of hardware and computer software. Whether a function is performed as hardware or computer software drives hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiment of the present application, the functional modules of the devices involved in the method may be divided according to the above method example, for example, each functional module may be divided corresponding to each function, or two or more functions may be integrated into one processing module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode. It should be noted that, in the embodiment of the present application, the division of the module is schematic, and is only one logic function division, and another division manner may be available in actual implementation.

As shown in fig. 9, an apparatus 900 for running an application provided in the embodiment of the present application is applied to an electronic device. In some embodiments, the electronic device has a first application installed therein, the first application including a first function therein, and the apparatus includes: a loading unit 901, configured to load the first application program in the first process. An interpreting executing unit 902, configured to interpret to execute the first function in the first process. A compiling unit 903, configured to perform compiling on the first function after a number of times of interpreting and executing the first function reaches a first compiling threshold of the first function in the first process. A storage unit 904, configured to store a result of the compiling performed by the first function in a shared code cache, where the shared code cache is accessible to at least a process in the electronic device.

In a possible design, a second application program is further installed in the electronic device, where the second application program includes the first function, and the loading unit 901 is configured to load the second application program in a second process. The second process is the same as the parent process of the first process. The apparatus further includes a reading unit 905, configured to read and execute a result of the first function executing the compiling from the shared code cache when the first function is called in the second process.

In a possible design, the electronic device stores a first function state record table, where the first function state record table is used to record storage addresses of different functions after compiling, and the reading unit 905 is used to read the first function state record table in the second process, and search, according to a function signature of the first function, whether a storage address corresponding to the first function exists in the first function state record table. The apparatus further includes an executing unit 906, configured to, when a memory address corresponding to the first function exists, read the compiled machine code of the first function from the memory address, and execute the compiled machine code of the first function.

In one possible design, before the first process stores a result of the first function performing the compilation in a shared code cache, the apparatus further includes: an updating unit 907 is configured to establish/update a memory address of the first function after the first function is compiled in the first function state record table.

In a possible design, when the storage address corresponding to the first function does not exist in the first function state record table, the interpretation and execution unit 902 is configured to interpret and execute the first function in the second process.

In one possible design, the apparatus further includes: a determining unit 908 configured to determine that the first function is called by a plurality of different processes before performing the compiling on the first function in the first process.

In one possible design, a function access record table corresponding to the first function is stored in the electronic device. A reading unit 905, configured to read the function access record table. A determining unit 908, configured to determine that the first function is called by a plurality of different processes according to the function access record table, where at least one third process calls the first function. The third process is different from the first process.

In a possible design, the updating unit 907 is configured to, when the third procedure calls the first function, create/update a first table entry corresponding to the first function in the function access record table, where the first table entry is used to indicate the number of times that the first function is called by the third procedure.

In a possible design, the updating unit 907 is configured to, when the first process calls the first function, create/update a second entry corresponding to the first function in the function access record table, where the second entry is used to indicate the number of times that the first function is called by the first process.

In a possible design, the compiling unit 903 is configured to perform compiling on the first function after the number of times of interpreting and executing the first function in the first process reaches a second compiling threshold of the first function, and the storing unit 904 is configured to store a result of performing compiling on the first function in a private code cache of the first process.

In a possible design, the reading unit 905 is configured to, when the first function is called again in the first process, read and execute the machine code obtained by compiling the first function from the private code cache.

In a possible design, the electronic device stores a second function state record table, where the second function state record table is used to record the memory address of a different function after compiling in the first process, and the reading unit 905 is used to read the second function state record table in the first process, and to find whether the memory address corresponding to the first function exists in the second function state record table according to the function signature of the first function. And when the storage address corresponding to the first function exists, reading the compiled machine code of the first function from the storage address, and executing the compiled machine code of the first function.

In a possible design, before the result of compiling the first function is stored in the private code cache of the first process, the updating unit 907 is configured to establish/update the storage address of the second function state record table after compiling the first function.

In a possible design, when the storage address corresponding to the first function does not exist in the second function state record table, the reading unit 905 is configured to read the first function state record table in the first process, and find whether the storage address corresponding to the first function exists in the first function state record table according to the function signature of the first function. When the memory address corresponding to the first function exists, the compiled machine code of the first function is read from the memory address, and the execution unit 906 is configured to execute the compiled machine code of the first function.

In a possible design, when the storage address corresponding to the first function does not exist in the first function state record table, the interpretation and execution unit 902 is configured to interpret and execute the first function in the first process.

In one possible design, the apparatus further includes: a garbage collection unit 909 is configured to perform garbage collection on the shared code cache according to the load condition of the memory.

In one possible design, the load condition of the memory includes a light memory load and a heavy memory load. When the usage rate of the memory is higher than the first threshold and lower than the second threshold, the electronic device determines that the load condition of the memory is a light memory load, and the garbage collection unit 909 is configured to sequentially perform garbage collection on the machine codes obtained by compiling the functions that have not been called in the first function state record table.

In one possible design, the load condition of the memory includes a light memory load and a heavy memory load. When the utilization rate of the memory is higher than the second threshold, the electronic device determines that the load condition of the memory is a memory overload, and the garbage collection unit 909 is configured to sequentially perform garbage collection on the machine codes obtained by compiling the functions according to the sequence that the number of times of calling the machine codes obtained by compiling the functions in the first function state record table is as small as large.

It should be noted that all relevant contents of each step related to the method embodiment may be referred to the functional description of the corresponding functional module, and are not described herein again.

Fig. 10 shows a schematic composition diagram of an electronic device 1000. As shown in fig. 10, the electronic device 1000 may include: a processor 1001 and a memory 1002. The memory 1002 is used to store computer-executable instructions. For example, in some embodiments, when the processor 1001 executes the instructions stored in the memory 1002, the electronic device 1000 may be caused to execute the method for running the application program according to any one of the above embodiments.

It should be noted that all relevant contents of each step related to the above method embodiment may be referred to the functional description of the corresponding functional module, and are not described herein again.

Fig. 11 shows a schematic block diagram of a chip system 1100. The chip system 1100 may include: a processor 1101 and a communication interface 1102 for supporting associated devices to implement the functions referred to in the previous embodiments. In one possible design, the system-on-chip further includes a memory for storing necessary program instructions and data for the terminal. The chip system may be formed by a chip, or may include a chip and other discrete devices. It should be noted that, in some implementations of the present application, the communication interface 1102 may also be referred to as an interface circuit.

The functions or actions or operations or steps, etc., in the above embodiments may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using a software program, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. The procedures or functions described in accordance with the embodiments of the present application are all or partially generated upon loading and execution of computer program instructions on a computer. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored on a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website, computer, server, or data center to another website, computer, server, or data center via wire (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or can comprise one or more data storage devices, such as a server, a data center, etc., that can be integrated with the medium. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid State Disk (SSD)), among others.

Although the present application has been described in conjunction with specific features and embodiments thereof, it will be evident that various modifications and combinations can be made thereto without departing from the spirit and scope of the application. Accordingly, the specification and drawings are merely illustrative of the present application as defined in the appended claims and are intended to cover any and all modifications, variations, combinations, or equivalents within the scope of the application. It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include such modifications and variations.

Claims

1. An application program running method is applied to an electronic device, a first application program is installed in the electronic device, the first application program comprises a first function, and the method comprises the following steps:

loading the first application program in a first process;

interpreting execution of the first function in the first process;

compiling the first function after the number of times of interpreting and executing the first function reaches a first compiling threshold value of the first function in the first process;

storing a result of the first function performing the compilation in a shared code cache, the shared code cache being accessible to at least a process in the electronic device.

2. The method according to claim 1, wherein a second application is further installed in the electronic device, and the second application includes the first function therein, and the method further comprises:

loading the second application program in a second process; the second process is the same as the parent process of the first process;

and when the first function is called in the second process, reading and running a result of compiling execution of the first function from the shared code cache.

3. The method according to claim 2, wherein the electronic device stores a first function state record table, the first function state record table is used for recording the memory addresses of different functions after compiling,

the second process reads and runs the result of the first function execution compilation from the shared code cache, and the result comprises the following steps:

reading the first function state record table in the second process, and searching whether a storage address corresponding to the first function exists in the first function state record table according to the function signature of the first function;

and when a storage address corresponding to the first function exists, reading the compiled machine code of the first function from the storage address, and executing the compiled machine code of the first function.

4. The method of claim 3, wherein before the first process stores results of the compilation performed by the first function in a shared code cache, the method further comprises:

and the first process establishes/updates the memory address of the first function after compiling in the first function state record table.

5. The method according to claim 3 or 4, wherein when the memory address corresponding to the first function does not exist in the first function state record table, the method further comprises:

interpreting execution of the first function in the second process.

6. The method of any of claims 1-5, wherein prior to performing the compilation of the first function in the first process, the method further comprises:

determining that the first function is called by a plurality of different processes.

7. The method according to claim 6, wherein a function access record table corresponding to the first function is stored in the electronic device;

the determining that the first function is called by a plurality of different processes comprises:

reading the function access record table, and determining that the first function is called by a plurality of different processes according to the fact that at least one third process exists in the function access record table and calls the first function; the third process is different from the first process.

8. The method of claim 7, further comprising:

when the third process calls the first function, establishing/updating a first table entry corresponding to the first function in the function access record table, wherein the first table entry is used for indicating the times of calling the first function by the third process.

9. The method of claim 7 or 8, further comprising:

when the first process calls the first function, establishing/updating a second table entry corresponding to the first function in the function access record table, wherein the second table entry is used for indicating the times of calling the first function by the first process.

10. The method of any of claims 1-9, wherein no inline optimization is used in the compilation process.

11. The method of claim 10, further comprising:

performing compilation on the first function after the number of interpretations for executing the first function reaches a second compilation threshold for the first function in the first process,

storing a result of the first function performing compilation in a private code cache of the first process.

12. The method of claim 11, further comprising:

and in the first process, when the first function is called again, reading and executing the machine code obtained by compiling the first function execution from the private code cache.

13. The method according to claim 12, wherein a second function state record table is stored in the electronic device, the second function state record table is used for recording the memory addresses of different functions after compiling in the first process,

the reading and executing the machine code obtained by compiling the first function execution from the private code cache comprises:

reading the second function state record table in the first process, and searching whether a storage address corresponding to the first function exists in the second function state record table according to the function signature of the first function;

14. The method of claim 13, wherein prior to storing a result of the compiling of the first function execution in a private code cache of the first process, the method further comprises:

and the first process establishes/updates the memory address of the first function after compiling in the second function state record table.

15. The method according to claim 13 or 14, wherein when the storage address corresponding to the first function does not exist in the second function state record table, the method further comprises:

reading the first function state record table in the first process, and searching whether a storage address corresponding to the first function exists in the first function state record table according to the function signature of the first function;

16. The method according to claim 15, wherein when the first function state record table does not have a storage address corresponding to the first function, the method further comprises:

interpreting execution of the first function in the first process.

17. The method according to any one of claims 1-16, further comprising:

and the electronic equipment executes garbage collection on the shared code cache according to the load condition of the memory.

18. The method of claim 17, wherein the memory loading conditions include light memory load, heavy memory load;

when the usage rate of the memory is higher than a first threshold and lower than a second threshold, the electronic device determines that the load condition of the memory is a memory light load, and the performing garbage collection on the shared code cache includes:

and the electronic equipment sequentially executes garbage collection on machine codes obtained by compiling the functions which are not called in the first function state record table.

19. The method according to claim 17 or 18, wherein the load condition of the memory comprises a light memory load, a heavy memory load;

when the utilization rate of the memory is higher than a second threshold, the electronic device determines that the load condition of the memory is a memory reload, and the performing garbage collection on the shared code cache comprises:

and the electronic equipment executes garbage collection on the machine codes obtained by compiling the functions in sequence according to the sequence that the called times of the machine codes obtained by compiling the functions in the first function state record table are from small to large.

20. An application program running device, applied to an electronic device, in which a first application program is installed in the electronic device, the first application program including a first function, the application program running device being configured to implement the application program running method according to any one of claims 1 to 19.

21. An electronic device, comprising one or more processors and one or more memories; the one or more memories coupled with the one or more processors, the one or more memories storing computer instructions;

the computer instructions, when executed by the one or more processors, cause the electronic device to perform a method of running the application program of any of claims 1-19.

22. A computer-readable storage medium, comprising computer instructions, which, when executed on an electronic device, cause the electronic device to perform a method of running an application program according to any one of claims 1-19.

23. A computer program product comprising instructions which, when run on a computer, make it possible for the computer to carry out the method of running an application according to any one of claims 1 to 19 in accordance with the instructions.