A method of compilation optimization and electronic device

Abstract

This application provides a compilation optimization method and an electronic device. The method includes: obtaining first information based on the operating information of the electronic device; in a target scenario, when the first information satisfies the activation conditions of PGO and the PGO is closed, activating the PGO; the target scenario includes a deopt deoptimization scenario, a memory change rate scenario, a mixed AOT and JIT compilation scenario, and a mixed AOT and interpreter execution scenario; and deactivating the PGO when the PGO finishes running. This method enables flexible activation and deactivation of the PGO, effectively reducing the daily operating overhead caused by data collection.

Description

Technical Field

[0001] This application relates to the field of electronic device technology, and in particular to a compiler optimization method and an electronic device. Background Technology

[0002] Currently, to continuously optimize code, Profile Guided Optimization (PGO) is often performed during application runtime to collect application application files (ap files). The application is then compiled based on the information in the ap files to obtain optimized code, which is then used to further refine and improve the application. However, current PGO solutions suffer from poor flexibility and high system overhead. Summary of the Invention

[0003] This application provides a compilation optimization method and an electronic device to improve the flexibility of PGO and reduce system overhead.

[0004] In a first aspect, embodiments of this application provide a compilation optimization method, which is applied to an electronic device. The method includes: obtaining first information based on the operating information of the electronic device; in a target scenario, when the first information satisfies the activation conditions of PGO and the PGO is closed, activating the PGO; the target scenario includes a deopt deoptimization scenario, a memory change rate scenario, a mixed AOT and JIT compilation scenario, and a mixed AOT and interpreter execution scenario; and when the PGO finishes running, closing the PGO.

[0005] For example, embodiments of this application can obtain overall operating information of an electronic device and obtain first information from the overall operating information of the electronic device; or, embodiments of this application can selectively obtain operating information of applications in the electronic device and obtain first information based on the operating information of the application, without limitation. Furthermore, embodiments of this application can obtain first information in a timely manner during application operation, or obtain first information from feedback information of application operation after the application has finished running, without limitation.

[0006] For example, embodiments of this application may further include PGO shutdown conditions. When the PGO shutdown conditions are met, the PGO is shut down. The PGO shutdown conditions include, but are not limited to, the termination of PGO execution. The termination of PGO execution in embodiments of this application may include the compiler having completed optimization of the corresponding program using collected performance data, i.e., the completion of the entire PGO process; or, the termination of PGO execution in embodiments of this application may also include PGO execution termination due to execution interruption. Execution interruption includes, but is not limited to, PGO interruption triggered by the system load exceeding a set load limit, or PGO interruption triggered by the corresponding application needing to continue running based on existing program code, etc., and is not limited here.

[0007] This method, by designing start and stop conditions for PGO, enables more flexible start and stop of PGO when the start conditions are met. For example, embodiments of this application can flexibly start and stop PGO based on the target scenario, effectively reducing the daily operating overhead caused by PGO, and avoiding situations where PGO cannot be stopped once started or cannot be started again once stopped. This method offers greater flexibility and adaptability, and a better user experience.

[0008] In one possible design, the first information includes any one or more of the following:

[0009] Depot information, memory change rate information, JIT compiled function information, function execution information;

[0010] The depot information includes one or more of the depot function and the number of depot operations; the memory change rate information includes one or more of the function execution time, function popularity, number of objects created by the function, or number of applications using the same function; the JIT compiled function information includes one or more of the functions that are executed by JIT compilation and the number of times the functions are executed by JIT compilation; and the function execution information includes popularity counts for at least one function.

[0011] For example, the function popularity in this application embodiment can be understood as the frequency of a function being called or the amount of execution time during program operation, which is used to measure the activity level of a method in the application.

[0012] For example, the Hotness Count in this application embodiment can refer to a metric used in certain systems or applications to measure the frequency with which a specific element (such as a code path, function, file, webpage, etc.) is accessed or used. For instance, the Hotness Count in this application embodiment can be understood as a counter used to track the number of times a code segment (such as a method or loop) is executed at runtime.

[0013] In one possible design, the target scenario is a deopt scenario, and the first information includes the deopt information; or, the target scenario is a memory change rate scenario, and the first information includes the memory change rate information; or, the target scenario is a mixed AOT and JIT compilation scenario, and the first information includes the function information compiled by JIT; or, the target scenario is a mixed AOT and interpreter execution scenario, and the first information includes the function execution information.

[0014] Through this method, the first information in the embodiments of this application is associated with the target scene, and the first information can be obtained more specifically based on different target scenes. This makes the obtained first information more helpful in determining whether the PGO activation conditions are met in the corresponding target scene. In addition, it can also effectively reduce the overhead of subsequent information processing.

[0015] In one possible design, the activation conditions of the PGO include any one or more of the following:

[0016] The number of deopt updates exceeds a first threshold, which is the upper limit for the number of deopt updates; the deopt function comes from pre-compiled AOT; the deopt function comes from just-in-time (JIT) compilation; the runtime memory change rate of the function exceeds a second threshold, which is the upper limit for the runtime memory change rate of the function; the number of applications using functions with a memory change rate exceeding the second threshold exceeds a third threshold, which is the upper limit for the number of applications; the number of times the same function is JIT compiled exceeds a fourth threshold, which is the upper limit for the number of times JIT compilation is performed on the same function; there are unoptimized hot functions, including functions whose popularity count exceeds a fifth threshold, which is the upper limit for the popularity count of functions that determine that they are not hot functions; the number of unoptimized hot functions exceeds a sixth threshold, which is the upper limit for the number of unoptimized hot functions.

[0017] Through this method, different PGO activation conditions are set in the embodiments of this application. In actual application, the appropriate PGO activation conditions can be selected based on the current scenario requirements. For example, PGO activation conditions can be selected in a targeted manner for different target scenarios, and whether to enable PGO can be determined based on the PGO activation conditions under the target scenario, which makes it more adaptable.

[0018] In one possible design, the target scenario is a deopt scenario, and the first information satisfies the PGO activation conditions, including:

[0019] The first information includes a first depot function that comes only from AOT, and the number of deopt updates of the first deopt function exceeds the first threshold; or, the first information includes a first depot function that comes only from JIT, and the number of deopt updates of the first deopt function exceeds the first threshold; or, the first information includes a first depot function that comes partly from AOT and partly from JIT, and the number of deopt updates of the first deopt function exceeds the first threshold.

[0020] This method, as described in this application, provides a way to determine when to enable PGO in a deopt scenario. It effectively addresses the problem of inflexible enabling and disabling of PGO in the deopt scenario, reduces the daily operating overhead of executing PGO in the deopt scenario, and avoids situations where PGO cannot be stopped once enabled or cannot be restarted once disabled in the deopt scenario. It is highly targeted, flexible, adaptable, and provides a better user experience.

[0021] In one possible design, the target scenario is a memory change rate scenario, and the first information satisfies the PGO enabling conditions, including:

[0022] The memory change rate of the first function included in the first information exceeds the second threshold; and / or, the number of applications of the first function exceeds the third threshold.

[0023] This method, as described in this application, provides a way to determine when to enable PGO based on memory change rate scenarios. It effectively compensates for the inability to flexibly enable and disable PGO in memory change rate scenarios, reduces the daily operating overhead caused by executing PGO in memory change rate scenarios, and avoids situations where PGO cannot be ended once enabled or cannot be enabled again once disabled in memory change rate scenarios. It is highly targeted, flexible, and adaptable, and provides a better user experience.

[0024] In one possible design, the target scenario is a hybrid AOT and JIT environment, and the first information satisfies the PGO enabling conditions, including:

[0025] The first information includes functions that have been executed JIT compilation more than the fourth threshold.

[0026] This method, as described in this application, provides a way to determine when PGO is enabled in a hybrid AOT and JIT programming scenario. It effectively addresses the problem of inflexibly enabling and disabling PGO in hybrid AOT and JIT programming scenarios, reduces the daily operating overhead of executing PGO in these scenarios, and avoids situations where PGO cannot be stopped once enabled or cannot be restarted once disabled. This method is highly targeted, flexible, adaptable, and provides a better user experience.

[0027] In one possible design, the target scenario is a hybrid AOT and interpreter operation scenario, and the first information satisfies the PGO activation conditions, including:

[0028] The first information includes function execution information containing hotspot functions, and the number of unoptimized hotspot functions exceeds the sixth threshold.

[0029] This application provides a method for determining when to enable PGO in a mixed AOT and interpreter operation scenario. This effectively addresses the problem of inflexible enabling and disabling of PGO in such scenarios, reduces the daily operational overhead of executing PGO, and avoids situations where PGO cannot be terminated once enabled or disabled once disabled. This method is highly targeted, flexible, adaptable, and provides a better user experience.

[0030] In one possible design, the method further includes:

[0031] Second information is obtained based on the operating information of the electronic device; in the target scenario, when the second information satisfies the activation condition of the PGO and the PGO is closed, the PGO is activated; when the PGO finishes running, the PGO is deactivated.

[0032] Using this method, in this embodiment of the application, PGO can be started when the start conditions of PGO are met based on the first information obtained, and PGO can be closed after PGO finishes running. When the start conditions of PGO are determined again based on the second information obtained subsequently, PGO can be started again, and PGO can be closed after PGO finishes running, thus effectively realizing flexible start and stop of PGO.

[0033] In one possible design, the method further includes:

[0034] Before enabling PGO, determine if some or all of the applications corresponding to the running information are in the whitelist; the whitelist includes a list of applications that are allowed to enable PGO.

[0035] This method enables more targeted PGO activation, enhancing the security of PGO activation. For example, in this embodiment, applications that allow compilation optimization can be placed in a whitelist; or, applications with higher security levels can be placed in a whitelist. It is understood that the whitelist can be set in various ways and can be updated according to actual conditions, and no limitation is made here.

[0036] In a second aspect, this application provides an electronic device, the electronic device including a memory and one or more processors; wherein the memory is used to store computer program code, the computer program code including computer instructions; when the computer instructions are executed by the one or more processors, the electronic device causes the electronic device to perform the method applied to any device described in the first aspect or any possible design of the first aspect.

[0037] Thirdly, this application provides a computer-readable storage medium storing a computer program that, when run on an electronic device, causes the electronic device to perform the method described in the first aspect or any possible design of the first aspect for application to any device.

[0038] Fourthly, this application provides a computer program product comprising a computer program or instructions that, when executed on an electronic device, cause the electronic device to perform the method described in the first aspect or any possible design of the first aspect for application to any device.

[0039] Fifthly, this application provides a chip system including a processor and a memory, wherein the memory stores instructions; when the instructions are executed by the processor, they implement the method described in the first aspect or any possible design of the first aspect, applicable to any device. The chip system may be composed of chips or may include chips and other discrete devices.

[0040] The beneficial effects of the second to fifth aspects mentioned above can be found in the beneficial effects of the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0041] Figure 1 A schematic diagram of the hardware architecture of an electronic device provided in an embodiment of this application;

[0042] Figure 2 A schematic diagram of the software architecture of an electronic device provided in an embodiment of this application;

[0043] Figure 3 This application provides a schematic diagram of the architecture of a PGO system.

[0044] Figure 4 This is a schematic diagram of a PGO system provided in an embodiment of this application;

[0045] Figure 5 This is a schematic diagram of another PGO system provided in an embodiment of this application;

[0046] Figure 6 A schematic diagram of a PGO process provided in an embodiment of this application;

[0047] Figure 7 A schematic diagram illustrating a compilation optimization method provided in an embodiment of this application;

[0048] Figure 8 A flowchart illustrating application scenario one provided in this application embodiment;

[0049] Figure 9 A flowchart illustrating application scenario two provided in this application embodiment;

[0050] Figure 10 A flowchart illustrating application scenario three provided in this application embodiment;

[0051] Figure 11 This is a flowchart illustrating application scenario four provided in the embodiments of this application;

[0052] Figure 12 A schematic diagram illustrating another compilation optimization method provided in an embodiment of this application;

[0053] Figure 13A schematic diagram illustrating another compilation optimization method provided in an embodiment of this application;

[0054] Figure 14 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0055] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings.

[0056] In the description of the embodiments of this application, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0057] It should be understood that in the embodiments of this application, "more than" means greater than, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, a and b, a and c, b and c, or a, b, and c, where a, b, and c can be single or multiple.

[0058] Currently, to continuously optimize code, PGO (Programmatic Execution and Goal) data collection is often performed during application runtime to obtain the application's .ap file. The application is then compiled based on the information in the .ap file to obtain optimized code. In this application's embodiments, PGO can refer to a compiler technology used to optimize code performance by analyzing the actual runtime behavior of a program. The working principle of PGO can include steps such as data collection and optimized compilation. For example, PGO can use data collected during program execution (i.e., configuration files) to recompile the program, optimizing critical paths, inline function calls, loop unrolling, etc., to improve performance and efficiency, reduce branch prediction failures and cache misses, and enhance overall code quality.

[0059] In current related technologies, for dynamic languages ​​like JS / ArkTS, inconsistencies may exist between the actual runtime type information and the sampled information during application execution. This can prevent the code from being optimized or lead to performance degradation due to deoptimization (depot) techniques. In this application's embodiments, deopt is a common compiler optimization technique. It refers to the compiler making aggressive optimization assumptions about the code; if these assumptions are proven wrong at runtime, the compiler will revert the optimized code to an unoptimized state and re-interpret and execute it.

[0060] To obtain the correct sampling type, it's necessary to continuously retrieve the profile. However, retrieving the profile incurs performance overhead, which may outweigh the benefits of optimization. For example, the mainstream JavaScript virtual machine engine is V8, which uses JIT (Just-In-Time) technology. During runtime, bytecode is compiled into machine code synchronously, and JIT information collection is a full-lifecycle PGO (Progressive Goal Optimization). The mainstream Android mobile operating system's ART virtual machine continuously performs PGO optimization throughout the application's lifecycle to ensure optimal runtime performance. However, this method of PGO itself incurs approximately 20% performance overhead, which can have significant side effects in scenarios where optimization is unnecessary or insignificant.

[0061] In summary, the currently available PGO solutions are inflexible and have high system overhead. Therefore, it is an important research direction to provide a flexible, efficient and energy-saving PGO solution.

[0062] Based on this, in order to reduce the overhead and improve the flexibility of the PGO scheme, embodiments of this application provide a compilation optimization method and electronic device. In this scheme, by controlling the timing of PGO acquisition on and off, and / or the conditions for restarting PGO after it has been turned off, this application effectively avoids PGO acquisition being enabled throughout the entire lifecycle, thus better reducing the performance degradation caused by PGO acquisition.

[0063] The solutions provided in this application can be applied to electronic devices or servers, or to a system consisting of multiple electronic devices and at least one server. Specific application methods can be found in the descriptions in the following embodiments.

[0064] In some embodiments of this application, the electronic device can be a portable device, such as a mobile phone, tablet computer, wearable device with wireless communication capabilities (e.g., watch, bracelet, etc.), in-vehicle terminal device, augmented reality (AR) / virtual reality (VR) device, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), smart home device (e.g., smart TV, smart speaker, etc.), smart robot, workshop equipment, wireless terminal in self-driving, wireless terminal in remote medical surgery, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, or wireless terminal in smart home, flying equipment (e.g., smart robot, drone, airplane), etc. Wearable devices are portable devices that users can wear directly on their body or integrate into their clothing or accessories.

[0065] In some embodiments of this application, the electronic device may also be a portable terminal device that includes other functions. Exemplary embodiments of the portable terminal device include, but are not limited to, carrying... Alternatively, it could be a portable terminal device with another operating system. The aforementioned portable terminal device could also be other portable terminal devices, such as a laptop computer with a touch-sensitive surface (e.g., a touch panel). It should also be understood that in some other embodiments of this application, the aforementioned electronic device may not be a portable terminal device, but rather a desktop computer with a touch-sensitive surface (e.g., a touch panel).

[0066] See below. Figure 1 The structure of the electronic device to which the method provided in the embodiments of this application is applicable will be described.

[0067] like Figure 1As shown, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a USB interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a SIM card interface 195, etc.

[0068] The sensor module 180 may include a gyroscope sensor, an accelerometer, a proximity sensor, a fingerprint sensor, a touch sensor, a temperature sensor, a pressure sensor, a distance sensor, a magnetic sensor, an ambient light sensor, a barometric pressure sensor, a bone conduction sensor, etc.

[0069] Understandable, Figure 1 The electronic device 100 shown is merely an example and does not constitute a limitation on the electronic device. The electronic device may have more or fewer components than those shown in the figure, may combine two or more components, or may have different component configurations. Figure 1 The various components shown can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application-specific integrated circuits.

[0070] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, memory, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). Different processing units may be independent devices or integrated into one or more processors. The controller may serve as the central nervous system and command center of the electronic device 100. The controller can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution.

[0071] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0072] The execution of the compilation optimization method provided in this application embodiment can be controlled by the processor 110 or by calling other components. For example, it can call the processing program of this application embodiment stored in the internal memory 121, or call the processing program of this application embodiment stored in a third-party device through the external memory interface 120 to control the wireless communication module 160 to perform data communication with other devices, thereby improving the intelligence and convenience of the electronic device 100 and enhancing the user experience. The processor 110 may include different devices. For example, when integrating a CPU and a GPU, the CPU and GPU can cooperate to execute the log processing method provided in this application embodiment. For example, some algorithms in the log processing method are executed by the CPU, and other algorithms are executed by the GPU to obtain faster processing efficiency.

[0073] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a Miniled LED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, electronic device 100 may include one or N displays screens 194, where N is a positive integer greater than 1. Display screen 194 can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces (GUIs). For example, display screen 194 can display photos, videos, web pages, or documents, etc.

[0074] In this embodiment of the application, the display screen 194 can be a single flexible display screen, or it can be a splicing display screen composed of two rigid screens and a flexible screen located between the two rigid screens.

[0075] Camera 193 (a front-facing camera or a rear-facing camera, or a single camera that can function as both) is used to capture still images or videos. Typically, camera 193 may include a photosensitive element such as a lens assembly and an image sensor. The lens assembly includes multiple lenses (convex or concave lenses) for collecting light signals reflected from the object being photographed and transmitting these signals to the image sensor. The image sensor generates a raw image of the object being photographed based on the light signals.

[0076] The internal memory 121 can be used to store computer executable program code, which includes instructions. The processor 110 executes various functional applications and data processing of the electronic device 100 by running the instructions stored in the internal memory 121. The internal memory 121 may include a program storage area and a data storage area. The program storage area can store the operating system, application program code (such as the functions corresponding to the scheme in this application), etc. The data storage area can store data created during the use of the electronic device 100.

[0077] The internal memory 121 may also store one or more computer programs corresponding to the algorithm of this application. The one or more computer programs are stored in the internal memory 121 and configured to be executed by one or more processors 110. The one or more computer programs include instructions that can be used to perform the various steps in the following embodiments.

[0078] In addition, the internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0079] Of course, the algorithm code of the embodiment of this application can also be stored in external memory. In this case, the processor 110 can run the algorithm code of the embodiment of this application stored in external memory through the external memory interface 120.

[0080] A touch sensor, also known as a "touch panel," can be located on the display screen 194. The touch sensor and display screen 194 together form a touch display screen, also called a "touch screen." The touch sensor detects touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through the display screen 194. In other embodiments, the touch sensor may also be located on the surface of the electronic device 100, in a different position than the display screen 194.

[0081] For example, the display screen 194 of the electronic device 100 can display a main interface, which includes icons for multiple applications (such as a camera application, a fitness and health application, etc.). For instance, a user can tap the camera application icon on the main interface using a touch sensor, triggering the processor 110 to launch the camera application and open the camera 193. The display screen 194 then displays the camera application's interface, such as the viewfinder.

[0082] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0083] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0084] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device. In this embodiment, the mobile communication module 150 can also be used for information interaction with other devices.

[0085] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through an audio device (not limited to speaker 170A, receiver 170B, etc.) or displays images or videos through the display screen 194. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 110 and may be housed in the same device as the mobile communication module 150 or other functional modules.

[0086] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLANs) (such as wireless fidelity (WiFi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2. In this embodiment, the wireless communication module 160 can be used to establish connections with other electronic devices for data interaction. Alternatively, the wireless communication module 160 can be used to access access point devices, send control commands to other electronic devices, or receive data from other electronic devices.

[0087] In addition, the electronic device 100 can implement audio functions through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, and an application processor, such as music playback and recording. The electronic device 100 can receive input from buttons 190, generating key signal inputs related to user settings and function control. The electronic device 100 can use a motor 191 to generate vibration alerts (such as vibration alerts for incoming calls). The indicator 192 in the electronic device 100 can be an indicator light, used to indicate charging status, battery level changes, messages, missed calls, notifications, etc. The SIM card interface 195 in the electronic device 100 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to achieve contact and separation with the electronic device 100.

[0088] It should be understood that, in practical applications, electronic device 100 may include more than Figure 1 The number of more or fewer components shown is not limited in the embodiments of this application. The illustrated electronic device 100 is merely an example, and the electronic device 100 may have more or fewer components than shown in the figure, may combine two or more components, or may have different component configurations. The various components shown in the figure may be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application-specific integrated circuits.

[0089] The software system of electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. A layered architecture divides the software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. For example, ... Figure 2 As shown, the software architecture can be divided into four layers, from top to bottom: the application layer, the application framework layer (framework, FWK), the runtime and system libraries, and the (Linux) kernel layer.

[0090] The application layer is the top layer of the operating system and includes native operating system applications such as camera, gallery, calendar, Bluetooth, and music, as well as third-party applications. The applications discussed in this application are referred to as apps (APPs), which are software programs capable of performing one or more specific functions. Typically, multiple apps can be installed on an electronic device, such as camera apps and email apps. The apps mentioned below can be system apps pre-installed at the factory or third-party apps downloaded by the user from the network or obtained from other electronic devices during use.

[0091] Of course, for developers, they can write applications and install them into this layer. In one possible implementation, the application can be developed using the Java language, by calling the application programming interface (API) provided by the application framework layer. Developers can then interact with the underlying operating system (such as the kernel layer) through the application framework to develop their own applications.

[0092] In some embodiments of this application, the application layer may include interactive applications, through which electronic devices can interact with other electronic devices. For example, interactive applications may include social applications (e.g., video calling applications), office applications (e.g., conferencing applications), etc., and the specific applications included in the interactive applications are not limited in this application. In one possible solution, the interactive application may also include a problem feedback module. The electronic device can receive user feedback (e.g., interaction quality issues) through the problem feedback module in the interactive application and upload the electronic device's log data to the server, so that the server can perform problem analysis based on the log data uploaded by the electronic device. In another possible solution, the application layer may also include a problem feedback application, through which the electronic device can receive user feedback (e.g., interaction quality issues) and upload the electronic device's log data to the server, so that the server can perform problem analysis based on the log data uploaded by the electronic device.

[0093] The application framework layer provides the API and programming framework for the application layer. It can include predefined functions. The application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc.

[0094] The window manager is used to manage window programs. The window manager can obtain the screen size, determine if a status bar is present, lock the screen (or display), and capture the screen, among other things.

[0095] Content providers are used to store and retrieve data, making that data accessible to applications. This data may include files (e.g., documents, videos, images, audio), text, and other information.

[0096] A view system includes visual controls, such as controls that display text, images, documents, and other content. View systems can be used to build applications. An interface in a display window can consist of one or more views. For example, a display interface including a text message notification icon could include a view that displays text and a view that displays images.

[0097] The phone manager provides communication functionality for electronic devices. The notification manager allows applications to display notification information in the status bar; it can be used to convey informative messages and can disappear automatically after a short pause without user interaction.

[0098] The runtime includes the core libraries and the virtual machine. The runtime is responsible for system scheduling and management.

[0099] The system's core library consists of two parts: one part contains the functionalities that the Java language needs to call, and the other part is the system's core library. The application layer and application framework layer run in a virtual machine. Taking Java as an example, the virtual machine executes the Java files in the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0100] The system library can include multiple functional modules. Examples include: a surface manager, a media library, a 3D graphics processing library (e.g., OpenGL ES), a 2D graphics engine (e.g., SGL), and an image processing library. The surface manager manages the display subsystem and provides fusion of 2D and 3D layers for multiple applications. The media library supports playback and recording of various common audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.564, MP3, AAC, AMR, JPG, and PNG. The 3D graphics processing library implements 3D graphics drawing, image rendering, compositing, and layer processing. The 2D graphics engine is the drawing engine for 2D graphics.

[0101] The kernel layer provides core system services for the operating system, such as security, memory management, process management, network protocol stack, and driver models, all of which are implemented based on the kernel layer. The kernel layer also serves as an abstraction layer between the hardware and software stacks. This layer contains many drivers related to electronic devices, including: display drivers; keyboard drivers as input devices; Flash drivers for memory-based devices; camera drivers; audio drivers; Bluetooth drivers; and WiFi drivers.

[0102] It is important to understand that the functional services described above are just an example. In practical applications, electronic devices may be divided into more or fewer functional services based on other factors, or the functions of each service may be divided in other ways, or they may not be divided into functional services but work as a whole.

[0103] The solutions provided in the embodiments of this application are described in detail below. The solutions provided in the embodiments of this application can be applied to a system consisting of multiple electronic devices and at least one server. For ease of explanation, the following description uses a scenario where the solutions provided in the embodiments of this application are applied to a system consisting of two electronic devices and one server as an example. The implementation method for scenarios involving a larger number of electronic devices and / or more servers can be implemented with reference to the methods provided in the following embodiments, and will not be listed and described in detail in this application.

[0104] Figure 3 This is a schematic diagram of the architecture of a PGO system provided in an embodiment of this application. Figure 3 As shown, the PGO system may include a first module, a second module, and a third module. It should be noted that in this embodiment, the first, second, and third modules can be virtual modules or physical modules, such as modules or units within a physical device. Furthermore, the number of the first, second, and third modules in this embodiment is not limited here, but can be adjusted according to actual needs. For example, the above... Figure 1 The PGO system can be installed in the electronic device shown, or it can be integrated via an interface or other means. Through the PGO system, the operating scenario of the electronic device can be determined during operation. When it is determined that PGO needs to be enabled or disabled, PGO can be enabled or disabled promptly, thus better optimizing the compilation of applications in the electronic device and effectively reducing the system overhead of compilation optimization. For example, in the embodiments of this application, the first module, the second module, and the third module can be as described above. Figure 1 The processor 110 shown contains processing modules (also referred to as operation modules, control modules, etc., which are not limited here), wherein the first module, the second module, and the third module can call the aforementioned... Figure 1 The internal memory 121 stores the corresponding computer-executable program code, thereby executing various functional applications and data processing of the module itself. The first module, second module, and third module can also store data generated during operation into the storage data area of ​​the internal memory 121; or, the first module, second module, and third module can call the aforementioned... Figure 1 The instruction code in the memory set in the processor 110, as well as the first module, second module, and third module, can store data and other contents generated during operation into the memory set in the processor 110; for example, in the embodiments of this application, the first module, second module, and third module can be the aforementioned Figure 1 The processor 110 shown calls an internal program module, which can be stored in the internal memory 121; for example, in this embodiment, the first module, the second module, and the third module can be the aforementioned... Figure 1 The processor 110 shown calls external program modules, such as the processing program of this application embodiment stored in a third-party device through the external memory interface 120, to execute the compilation optimization method provided in this application embodiment. It is understood that the above descriptions of the first module, second module, and third module are related to... Figure 1 The relationships between the electronic devices shown are merely an example of this application and do not constitute a limitation on the PGO system of this application. The first module, second module, and third module described in the embodiments of this application can also be the ones mentioned above. Figure 1 Components not shown in the text, or the first module, second module, and third module described in the embodiments of this application, may also be located in the above-mentioned... Figure 1 Other components shown, or implemented in hardware, software, or a combination of hardware and software including other signal processing and / or application-specific integrated circuits, are not limited herein.

[0105] In some implementations, the first, second, and third modules of this PGO system can interact, applicable to scenarios where applications run on mobile phones, tablets, and computers. PGO collection is dynamically enabled and disabled during application operation to achieve optimal performance. This embodiment does not restrict specific application types or operating methods. In this embodiment, the third module can determine whether the current scenario meets the conditions for enabling or disabling PGO based on the PGO enabling or disabling conditions provided in this application. When the PGO disabling conditions are met, PGO is disabled. When PGO is enabled, it can interact with the first and / or second modules to achieve compilation optimization. The first module can further interact with the second module to achieve code compilation optimization, effectively avoiding full-cycle PGO collection and better reducing the performance degradation caused by PGO collection.

[0106] For example, in the solution provided in this application embodiment, the third module can be a processing module, the second module can be a virtualizer, and the first module can store program code. The virtualizer can be a virtual computer system created by virtualization software, sharing the physical resources of the host system and operating in isolation from the host system. Different virtualizers can run independent operating systems and applications. For example, such as... Figure 4As shown, different second modules in this application embodiment can correspond to different first modules, and different second modules can correspond to the same third module. For example, application 1 corresponds to virtual machine 1, application 2 corresponds to virtual machine 2, and the processing module corresponds to virtual machine 1 and virtual machine 2. It is used to obtain profile data from the virtual machine, and then analyze it based on the profile data. When the PGO is enabled or disabled based on the conditions provided in this application, it determines whether the current scene meets the conditions for enabling or disabling PGO. When the conditions for disabling PGO are met, PGO is disabled; when the conditions for enabling PGO are met, optimized compilation is performed. For example, as shown in the example... Figure 5 As shown, in this application embodiment, different second modules correspond to different first modules, and different second modules correspond to different processing modules. For example, application 1 corresponds to virtual machine 1, application 2 corresponds to virtual machine 2, processing module 1 corresponds to virtual machine 1, and processing module 2 corresponds to virtual machine 2. Processing module 1 is used to obtain Profile data 1 from virtual machine 1, and then analyze it based on Profile data 1. When based on the PGO enable or disable conditions provided in this application, it determines whether the current Profile data 1 meets the PGO enable or disable conditions. When the PGO disable condition is met, PGO disable is triggered. When PGO enable is met, the optimized compilation of application 1 is executed. Processing module 2 is used to obtain Profile data 2 from virtual machine 2, and then analyze it based on Profile data 2. When based on the PGO enable or disable conditions provided in this application, it determines whether the current Profile data 2 meets the PGO enable or disable conditions. When the PGO disable condition is met, PGO disable is triggered. When PGO enable is met, the optimized compilation of application 2 is executed.

[0107] In some implementations of the PGO system, the aforementioned processing modules may include, but are not limited to, the first processing module and the second processing module.

[0108] For example, the first processing module has at least, but is not limited to, the following functions:

[0109] Function 1: Responsible for handling the installation and uninstallation of applications.

[0110] Function 2: Responsible for decompressing APK files and installing them into the system.

[0111] Function 3: Manage application storage space and permissions.

[0112] As an example, in this embodiment, the first processing module is a security service module (installd). Installd is a system service in the Android operating system responsible for managing the installation process of application packages (APK files). For example, when installation, update, or uninstallation is required, the system communicates with installd through PackageManagerService. Installd runs as a local daemon process, silently performing its tasks in the background, typically without direct user intervention.

[0113] For example, the second processing module has at least, but is not limited to, the following functions:

[0114] Function 1: Discover potential bugs, security vulnerabilities, and code quality issues.

[0115] Function 2: Perform code repairs to improve code quality and security.

[0116] As an example, in this embodiment, the second processing module is a static analysis module, such as compile SA. Static analysis is a technique that examines code before execution to discover potential errors, security vulnerabilities, and code quality issues. Static analysis tools are widely used in software development to help developers identify and fix problems in early stages, improving code quality and security.

[0117] In some implementations, the virtualizer in this PGO system has at least, but is not limited to, the following functions:

[0118] Function 1: Responsible for interpreting (also known as compiling) and executing JavaScript code.

[0119] In this application, "interpreting JavaScript code" can be understood as converting JavaScript code into machine code or bytecode.

[0120] Optionally, the JavaScript code involved in this application embodiment can be a cleaned version of ECMAScript code, which is not limited here. Here, "cleaned version" in this application embodiment generally refers to a version that has been processed, cleaned, or modified to remove sensitive information, erroneous content, or non-compliant parts. The "cleaned version of ECMAScript code" in this application embodiment can be understood as JavaScript code that has been cleaned, optimized, or standardized. For example, removing unnecessary characters (such as redundant spaces, comments, etc.) from JavaScript code makes the code cleaner and easier to read; deleting unused variables, functions, or modules from JavaScript code reduces code size and improves performance; improving the compatibility of JavaScript code; ensuring that the code conforms to specific security standards or internal enterprise coding specifications, and removing potential security risks (such as XSS attacks, SQL injection, etc.).

[0121] As an example, the virtual machine in this application embodiment includes, but is not limited to, the ECMAScript virtual machine, which is responsible for interpreting and executing ECMAScript code. It can run in various environments, including browsers, servers, and embedded devices, etc., and this application embodiment does not limit it.

[0122] As an example, the PGO process in this application is not specifically limited to performing Profile data collection. For instance, in the actual operation of an application, Profile data is collected by recording information such as which functions are frequently called, which code takes a long time to execute, and memory allocation. Then, it can be referred to as... Figure 6 As shown, based on the collected profile data, the compiler can optimize the application's source code. The machine code generated by the compiler through PGO optimization can better adapt to the actual runtime situation and improve execution efficiency.

[0123] As an example, the compilation optimization strategies implemented in the embodiments of this application include, but are not limited to, one or more of the following:

[0124] Compiler optimization strategy 1: Function inlining.

[0125] For example, embodiments of this application can directly embed commonly used function bodies into the calling location to reduce the overhead of function calls.

[0126] Compiler optimization strategy 2: Code rearrangement.

[0127] For example, embodiments of this application can centrally place frequently executed code blocks in a specific memory region, thereby improving the CPU cache hit rate.

[0128] Compiler optimization strategy 3: Avoid unnecessary memory allocation.

[0129] For example, embodiments of this application can identify high-frequency memory allocation and release operations and optimize them for pooling management or lazy loading.

[0130] As an example, the types of profile data collected in embodiments of this application include, but are not limited to, one or more of the following:

[0131] Data type 1: Execution frequency.

[0132] For example, embodiments of this application can obtain the frequency of function or code path execution, such as which functions or code paths are frequently executed and which are rarely executed.

[0133] Data type 2: Execution time.

[0134] For example, embodiments of this application can obtain the execution time of a function. For instance, the execution time can be obtained for tasks or functions that are CPU-intensive or computationally intensive.

[0135] Data type 3: Memory allocation.

[0136] For example, embodiments of this application can obtain the memory allocation amount of each function, such as obtaining relevant data on high-frequency content allocation and release operations.

[0137] Data type 4: CPU usage.

[0138] For example, embodiments of this application can obtain the CPU time occupied by the target function or code.

[0139] As an example, embodiments of this application may include multiple virtualizers, which may be used to perform different functions and acquire and store different runtime information. For example, embodiments of this application may include four virtualizers.

[0140] It should be understood that the system architecture described above is only an example. In actual applications, some modules or devices can be added or removed from the interactive system, or some modules or devices can be split or merged. No specific restrictions are imposed in this application.

[0141] Based on the above embodiments and the same technical concept, this application also provides a compilation optimization method. This method can be applied to, but is not limited to, the system architecture described above, such as... Figure 7 As shown, the method may include:

[0142] S701: Obtain first information based on the operating information of the electronic device.

[0143] In some implementations, the embodiments of this application may obtain the first information in a timely manner during the application's operation, or may obtain the first information from the feedback information of the application's operation after the application has finished running; this is not limited here.

[0144] In some implementations, the first information in the embodiments of this application may include, but is not limited to, any one or more of the following:

[0145] (1) Depot information:

[0146] For example, depot information includes, but is not limited to, one or more of the depot function and the depot count.

[0147] (2) Memory change rate information:

[0148] For example, memory change rate information includes, but is not limited to, one or more of the following: function (or method, which is not limited here) execution time, function popularity, number of objects created by the function, or number of applications using the same function.

[0149] In this application embodiment, function popularity can be understood as the frequency of a function being called or the execution time of a function during program execution, used to measure the activity level of a method in the application.

[0150] (3) Function information compiled by Just-In-Time (JIT) compilation:

[0151] For example, the JIT-compiled function information includes, but is not limited to, functions that are JIT-compiled, and one or more of the number of times the functions are JIT-compiled.

[0152] (4) Function execution information:

[0153] For example, function execution information includes the hotness count for each of at least one function.

[0154] In some implementations, to effectively reduce the overhead of information processing and to obtain more targeted first information that better suits the current target scenario, the target scenario and the first information in this application embodiment may be correlated. For example, this application embodiment may obtain different first information based on different target scenarios. The target scenarios provided in this application embodiment include, but are not limited to, deopt scenarios, memory change rate scenarios, Ahead-Of-Time Compilation (AOT) and JIT mixed compilation scenarios, and AOT and interpreter mixed operation scenarios, etc.

[0155] As an example, the correlation between the target scene and the first information in this application embodiment includes, but is not limited to, one or more of the following:

[0156] Related content 1: The correlation between the depot scene and the first piece of information.

[0157] For example, the first information obtained in the depot scenario in this application embodiment may include, but is not limited to, depot information.

[0158] Related content 2: Correlation between memory change rate scenarios and first information.

[0159] For example, the first information obtained in the memory change rate scenario in the embodiments of this application may include, but is not limited to, memory change rate information.

[0160] Related content 3: The correlation between AOT and JIT mixed programming scenarios and the first information.

[0161] For example, the first information obtained in the embodiment of this application based on the mixed AOT and JIT compilation scenario may include, but is not limited to, function information for performing JIT compilation.

[0162] Related content 4: Correlation between the scenario of AOT and interpreter running in combination and the first information.

[0163] For example, the first information obtained in the embodiment of this application based on a hybrid AOT and interpreter operation scenario may include, but is not limited to, function execution information.

[0164] S702: In the target scenario, when the first information satisfies the conditions for enabling PGO and the PGO is off, enable the PGO.

[0165] In some implementations, the conditions for enabling PGO in the embodiments of this application include, but are not limited to, any one or more of the following:

[0166] The number of `deopt` updates exceeds a first threshold, which can be the upper limit of the number of `deopt` updates; the `deopt` function comes from pre-compiled AOT; the `deopt` function comes from just-in-time (JIT) compilation; the runtime memory change rate of the function exceeds a second threshold, which can be the upper limit of the runtime memory change rate of the function; the number of applications using functions with a memory change rate exceeding the second threshold exceeds a third threshold, which can be the upper limit of the number of applications; the number of times the same function is JIT compiled exceeds a fourth threshold, which can be the upper limit of the number of times JIT compilation is performed on the same function; there are unoptimized hot functions, including functions with a heat count exceeding a fifth threshold, which can be the upper limit of the heat count used to determine whether a function belongs to the hot functions category, i.e., if the heat count is greater than the upper limit, the function is confirmed as a hot function, and if it is less than or equal to the upper limit, the function is considered as a non-hot function; the number of unoptimized hot functions exceeds a sixth threshold, which can be the upper limit of the number of unoptimized hot functions.

[0167] In some implementations, the conditions for enabling PGO vary depending on the target scenario. To better align with the judgment of whether to enable PGO in the current target scenario, embodiments of this application can set corresponding PGO enabling conditions based on different target scenarios. The PGO enabling conditions in a certain scenario may be specific and not limited to the following:

[0168] Condition 1: The correspondence between the depot scene and the conditions for activating PGO.

[0169] As an example, when the target scenario is a depot scenario, the conditions for activating PGO include one or more of the following:

[0170] The number of deopt updates exceeds the first threshold; or,

[0171] The `deopt` function comes from the pre-compiled AOT; or,

[0172] The `deopt` function comes from Just-In-Time (JIT) compilation; or,

[0173] The deopt function can come from either JIT or AOT at the same time.

[0174] For example, based on the PGO activation conditions provided in condition content 1, this application embodiment determines that the PGO activation conditions are met based on the first information, and the situations in which PGO is activated include, but are not limited to, the following:

[0175] For example, in this embodiment, the third module can determine that at least one depot function included in the first information comes only from AOT, such as depot function 1 coming only from AOT, and the number of deopt updates of deopt function 1 exceeds a first threshold, then PGO is enabled; as another example, in this embodiment, the third module can determine that at least one depot function included in the first information comes only from JIT, such as depot function 2 coming only from JIT, and the number of deopt updates of deopt function 2 exceeds a first threshold, then PGO is enabled; as yet another example, in this embodiment, the third module can determine that at least one depot function included in the first information comes partly from AOT and partly from JIT, such as depot function 3 coming partly from AOT and partly from JIT, and the number of deopt updates of deopt function 3 exceeds a first threshold, then PGO is enabled.

[0176] Condition 2: The correspondence between memory change rate scenarios and PGO activation conditions.

[0177] As an example, when the target scenario is a memory change rate scenario, the conditions for enabling PGO include one or more of the following:

[0178] The rate of memory change during function runtime exceeds the second threshold; or,

[0179] The number of applications using the same method whose application memory change rate exceeds the threshold exceeds the third threshold.

[0180] For example, based on the PGO activation conditions provided in condition content 2, this application embodiment determines that the PGO activation conditions are met based on the first information. The situations in which PGO is activated include, but are not limited to, the following:

[0181] For example, in an embodiment of this application, the third module can determine that the memory change rate of the first function included in the first information exceeds a second threshold, and then enable PGO; as another example, in an embodiment of this application, the third module can determine that the number of applications of the first function included in the first information exceeds a third threshold, and then enable PGO; as yet another example, in an embodiment of this application, the third module can determine that the memory change rate of the first function included in the first information exceeds a second threshold, and the number of applications of the first function included in the first information exceeds a third threshold, and then enable PGO.

[0182] Condition 3: The correspondence between the mixed AOT and JIT programming scenarios and the conditions for enabling PGO.

[0183] As an example, when the target application scenario includes a mixed AOT and JIT compilation scenario, the conditions for enabling PGO include the number of times a certain function is compiled by JIT exceeding the fourth threshold.

[0184] For example, based on the PGO activation conditions provided in condition content 1, this application embodiment determines that the PGO activation conditions are met based on the first information. The situations in which PGO is activated include, but are not limited to, the following:

[0185] For example, in this embodiment of the application, the third module can determine that there is a function in the first information that performs JIT compilation more than the fourth threshold, and then enable PGO. The function information that performs JIT compilation includes, but is not limited to, the specific name of the function that performs JIT compilation and the number of times the function corresponding to that function name performs JIT compilation. For example, the function information that performs JIT compilation in the first information includes the function information of the first function and the function information of the second function. The function information of the first function includes the number of times the first function performs JIT compilation, and the function information of the second function includes the number of times the second function performs JIT compilation. When the third module determines that the number of times the first function performs JIT compilation is greater than the fourth threshold, and / or the number of times the second function performs JIT compilation is greater than the fourth threshold, then PGO is enabled.

[0186] Condition 4: The correspondence between the mixed operation scenario of AOT and interpreter and the conditions for enabling PGO.

[0187] As an example, when the target scenario includes a mixed AOT and interpreter running scenario, the conditions for enabling PGO include one or more of the following:

[0188] There are unoptimized hotspot functions, including functions whose hotness count exceeds a fifth threshold; or,

[0189] The number of unoptimized hotspot functions exceeds the sixth threshold.

[0190] For example, based on the PGO activation conditions provided in condition content 1, this application embodiment determines that the PGO activation conditions are met based on the first information. The situations in which PGO is activated include, but are not limited to, the following:

[0191] For example, in the third module of this application embodiment, if it is determined that there are hot functions in the function execution information included in the first information, and the number of unoptimized hot functions exceeds the sixth threshold, then PGO is enabled.

[0192] S703: When the PGO finishes running, shut down the PGO.

[0193] As an example, embodiments of this application can set shutdown conditions for PGO. When the shutdown conditions are met, the PGO is shut down. These shutdown conditions include, but are not limited to, the termination of PGO execution. Optionally, the termination of PGO execution in embodiments of this application may include the compiler having completed optimization of the corresponding program using collected performance data, i.e., the completion of the entire PGO process; or, the termination of PGO execution in embodiments of this application may also include termination of PGO execution due to execution interruption. Execution interruption includes, but is not limited to, PGO interruption triggered by the system load exceeding a set load limit, or PGO interruption triggered by the corresponding application needing to continue running based on existing program code, etc., and is not limited here.

[0194] By using the above method, this application embodiment designs the start and stop conditions for PGO, enabling more flexible start and stop of PGO when the start conditions are met. For example, this application embodiment can flexibly start and stop PGO based on the target scenario, effectively reducing the daily operating overhead caused by PGO, and avoiding situations where PGO cannot be stopped once started or cannot be started again once stopped. This results in greater flexibility and adaptability, and a better user experience.

[0195] To better illustrate the PGO solution provided in this application, the following sections describe different application scenarios, but are not limited to the following application examples:

[0196] Application Example 1: PGO execution scheme in the deopt scenario.

[0197] In the deopt scenario, during application runtime, this embodiment of the application allows for optimization operations to be performed in order to better debug the application and improve the user experience when running the application.

[0198] For example, embodiments of this application can trigger a program to degenerate from optimized code to interpreter execution when it is determined that the collected profile data does not match the actual data. The collected profile data refers to performance data collected during the PGO training run phase through the actual execution of the program, including but not limited to function call frequency, branch selection probability, loop iteration count, memory access patterns, and hot code regions. This collected profile data can be used to generate a profile file, which guides the compiler to perform more effective optimizations in subsequent optimization compilation phases. The actual runtime data refers to the program's real performance data and behavior when running in a real environment, including but not limited to actual workload, user input, system resource status (such as CPU, memory, disk I / O), and environment variables and configurations, reflecting the program's performance in actual use. Optionally, the workload of the collected information can be compared with that of the actual information. For example, the similarity of the input data, processing tasks, and running parameters can be analyzed. If the difference is large, it indicates that the collected information does not match the actual information. Alternatively, the performance indicators of the program can be monitored, such as measuring key performance indicators like CPU utilization, memory usage, response time, and throughput. If the performance does not improve significantly after optimization, or even decreases, it indicates that the collected information does not match the actual information. Alternatively, hotspot code analysis can be performed. For example, performance analysis tools can be used to check whether there are new hotspot codes in the optimized program, or whether the original hotspot codes have disappeared. If the hotspot codes have changed unexpectedly, it indicates that the collected information does not match the actual information. Alternatively, the abnormal behavior or errors during program execution can be monitored. For example, log analysis, exception handling mechanisms (such as try-catch blocks), and system monitoring tools (such as Sentry and Datadog) can be used to detect unexpected behavior. If the optimized program exhibits more exceptions, it indicates that the collected information does not match the actual information.

[0199] For example, JavaScript is a dynamic language, and the information collected during execution may differ from the actual execution information. In such cases, we need to update the PGO information. However, this process is more expensive than simply running the interpreter. Therefore, to improve system performance, reduce system overhead, and avoid performance degradation caused by deopt execution, this application embodiment can set targeted PGO enabling conditions based on the deopt scenario. Thus, PGO is enabled when the corresponding enabling conditions are met in the deopt scenario. Furthermore, this application embodiment can also set targeted PGO disabling conditions based on the deopt scenario. Thus, PGO is disabled when the corresponding disabling conditions are met in the deopt scenario. Through this solution, this application embodiment can effectively avoid situations where PGO cannot be disabled after being enabled, or where PGO cannot be re-enabled after being disabled, effectively improving the flexibility and adaptability of the system's PGO execution and effectively reducing system overhead.

[0200] As an example, the enabling conditions for PGO set in this deopt scenario in this application embodiment include, but are not limited to, one or more of the following:

[0201] Content 1: The number of deopt updates exceeds the first threshold.

[0202] For example, in this embodiment of the application, when it is determined that the runtime state is different from the compilation state, deopt can be triggered. At this time, it is necessary to try to collect information again, returning from compilation optimization to the interpreter scenario. When the number of deopt updates exceeds a first threshold, that is, when the correction action is always performed a certain number of times, it can be considered that the current application or function is too old and it is necessary to perform PGO operation by collecting data. Optionally, in this embodiment of the application, the first threshold can be predefined or indicated by other devices or equipment, and is not limited here.

[0203] Content 2: The deopt function comes from Ahead-Of-Time Compilation (AOT).

[0204] In some implementations, AOT (Ahead-of-Time) compilation in this application embodiment can refer to compilation performed after program development but before deployment. The source code is directly compiled into machine code specific to the platform, thus eliminating the need for additional compilation steps at runtime. However, because AOT compilation occurs before deployment, it cannot be dynamically optimized for specific runtime environments. The resulting machine code is fixed and difficult to respond to unknown future changes. If the application logic changes, the entire project must be recompiled. Nevertheless, it avoids the overhead of runtime compilation, making overall execution more efficient, especially suitable for resource-constrained scenarios such as mobile devices or embedded systems.

[0205] Content 3: The deopt function comes from Just-In-Time Compilation (JIT).

[0206] In some implementations, JIT in this application embodiment can refer to compilation at runtime. The code initially exists as bytecode or an intermediate representation, which is then converted into machine code by the JIT compiler before actual execution. JIT compilation can be optimized based on runtime conditions, such as hotspot code optimization and inlining expansion. This means that for certain types of workloads, especially those with repetitive patterns, JIT-compiled applications may exhibit better performance. Furthermore, because JIT compilation can adjust optimization strategies at runtime based on actual conditions, it offers greater flexibility and is highly advantageous for applications that require frequent updates or dynamic module loading.

[0207] The activation condition for PGO set in this deopt scenario can be any of the above content 1 to content 3, or any combination of multiple content 1 to content 3. For example, the activation condition for PGO set in this deopt scenario is that at least one depot function included in the first information comes solely from AOT, and the number of deopt updates for this depot function exceeds a first threshold; another example is that the activation condition for PGO set in this deopt scenario is that at least one depot function included in the first information comes solely from JIT, and the number of deopt updates for this depot function exceeds a first threshold; yet another example is that the activation condition for PGO set in this deopt scenario is that at least one depot function included in the first information comes partly from AOT and partly from JIT, and the number of deopt updates for this depot function exceeds a first threshold.

[0208] Based on this deopt scenario, the compilation optimization method provided in this application embodiment can be referred to Figure 8 .like Figure 8 As shown, the method may include:

[0209] S801: The third module obtains first information from the second module, the first information including depot information.

[0210] As an example, the depot information in this application embodiment includes, but is not limited to, the depot function, and / or, the number of depots.

[0211] S802: The third module determines whether the depot function comes from JIT based on the first information. If yes, execute S803; otherwise, execute S805.

[0212] As an example, when both AOT and JIT compilation scenarios exist in this application embodiment, it can be first determined whether the compilation originates from JIT. If it is determined that the compilation originates from JIT, it can be assumed to originate from AOT, that is, the depot function is determined to originate only from AOT or only from JIT. Similarly, this application embodiment can also first determine whether the compilation originates from AOT, without limitation.

[0213] S803: The third module determines whether the depot function comes from AOT based on the first information. If yes, execute S804; otherwise, execute S805.

[0214] S804: PGO is not enabled in the third module.

[0215] As an example, in this embodiment of the application, if it is determined that the deopt function comes from JIT, and the function also deopts in AOT, then the deopt function is recorded, and no further optimization or compilation is performed for the deopt function.

[0216] The depot function can be recorded, and the compilation will no longer be optimized for that depot function.

[0217] S805: The third module records the depot function and updates the corresponding depot count for the depot function.

[0218] As an example, when the depot function is detected for the first time in this embodiment, the depot function can be recorded, and the update count of the depot function can be recorded as 1. When the depot function is detected again, since the depot function has been recorded before, it is not necessary to record the depot function again. It is only necessary to increment the update count of the depot function by 1, and so on.

[0219] As an example, in this application embodiment, the depot function and the number of times the depot function is depotped can be recorded in memory or in a preset storage location, without limitation.

[0220] S806: The third module determines whether the number of times the depot function is executed exceeds the depot update threshold. If yes, execute S807; otherwise, execute S804.

[0221] S807: Enable PGO in the third module.

[0222] As an example, after the optimized compilation of the depot function is completed in this embodiment of the application, the depot function and / or the number of depot updates stored in the corresponding memory can be cleared.

[0223] As an example, in this embodiment of the application, after completing step S807, that is, after completing the optimized compilation for the depot function, PGO can be turned off.

[0224] It should be noted that when data collection is performed in this scenario one in the embodiments of this application, the data collection can be targeted, such as collecting only the deopt information involved in the deopt scenario, i.e., incrementally adding information; or, for example, collecting all the information involved in the deopt scenario, i.e., completely re-collecting, which is not limited here.

[0225] Application Example 2: PGO execution scheme in a memory change rate scenario.

[0226] During application operation, memory usage rate is a crucial indicator. To better debug applications, this embodiment can more accurately determine which functions or applications require compilation optimization based on the memory usage rate. For example, if memory usage increases significantly when running a method (also called a function or application, etc., without limitation), it indicates that the method's logic is complex. In this case, compiling optimization for that method often yields good results. Similarly, if a method creates more objects when running a method, it indicates that the method requires more memory allocation and may take longer. Compiling optimization for this method also yields good results. Therefore, to improve system performance, reduce system overhead, and address the issue of poor performance of methods with significant memory usage rate fluctuations, this embodiment can set targeted PGO enabling conditions based on the memory usage rate scenario. PGO is enabled when the corresponding enabling conditions are met under the specified memory usage rate scenario. Furthermore, this embodiment can also set targeted PGO disabling conditions based on the memory usage rate scenario. PGO is disabled when the corresponding disabling conditions are met under the specified memory usage rate scenario. With this solution, the embodiments of this application can effectively avoid situations such as PGO being unable to be closed after it is started, and PGO being unable to be started again after it is closed. This effectively improves the flexibility of the system in executing PGO, makes it more adaptable, and effectively reduces system overhead.

[0227] As an example, the activation conditions for PGO set in this memory change rate scenario in this application embodiment include, but are not limited to, one or more of the following:

[0228] Content 1: The rate of change in memory during method runtime exceeds the second threshold.

[0229] As an example, the memory change rate in this application embodiment may include, but is not limited to, the following information:

[0230] (1) Method time consumption.

[0231] For example, embodiments of this application may set a method time threshold to determine whether the method time exceeds a set time limit.

[0232] (2) Popularity of the method.

[0233] For example, embodiments of this application may set a method popularity threshold to determine whether the method popularity exceeds a set popularity limit.

[0234] (3) The number of objects created by the method.

[0235] For example, in the embodiments of this application, an object number threshold can be set to determine whether the number of objects created by the method exceeds the set popularity limit.

[0236] In some implementations, the second threshold can be a method time threshold, a method popularity threshold, or an object quantity threshold. For example, when the method time exceeds the method time threshold, it is determined that the method runtime memory change rate exceeds the second threshold; or when the method popularity exceeds the method popularity threshold, it is determined that the method runtime memory change rate exceeds the second threshold; or when the number of objects created by the method exceeds the object quantity threshold, it is determined that the method runtime memory change rate exceeds the second threshold.

[0237] In some implementations, the second threshold can also be determined by a combination of several thresholds, including method execution time threshold, method popularity threshold, and object quantity threshold. For example, the second threshold can be determined by weighting the method execution time threshold, method popularity threshold, and object quantity threshold, and is not limited to the following formula 1:

[0238] W = W1*A1 + W2*A2 + W3*A3 (Formula 1)

[0239] Where W represents the second threshold, W1 represents the method time threshold, W2 represents the method popularity threshold, W3 represents the object quantity threshold, and A1 to A3 can be any value from 0 to 1, etc.

[0240] For example, when the second threshold is determined jointly by the method time threshold and the method popularity threshold, if the method time exceeds the method time threshold and the method popularity exceeds the method popularity threshold, then it is determined that the method runtime memory change rate exceeds the second threshold; or, when the second threshold is determined jointly by the method time threshold and the object quantity threshold, if the method time exceeds the method time threshold and the number of objects created by the method exceeds the object quantity threshold, then it is determined that the method runtime memory change rate exceeds the second threshold, etc., without further limitations.

[0241] Content 2: The number of applications using methods whose memory change rate exceeds the second threshold exceeds the third threshold.

[0242] In some implementations, when the memory change rate of a certain method is determined to exceed a second threshold, the method and the number of applications using the method can be recorded to further determine whether the number of applications using the method exceeds a third threshold.

[0243] The activation condition for PGO in this memory change rate scenario can be any of the above-mentioned content 1 or content 2, or a combination of content 1 and content 2. For example, the activation condition for PGO in this memory change rate scenario is that the memory change rate of the first function included in the first information exceeds a second threshold; another example is that the activation condition for PGO in this memory change rate scenario is that the number of applications of the first function included in the first information exceeds a third threshold; yet another example is that the activation condition for PGO in this memory change rate scenario is that the memory change rate of the first function included in the first information exceeds a second threshold, and the number of applications of the first function included in the first information exceeds a third threshold. Based on this memory change rate scenario, a compilation optimization method provided in this application embodiment can be referred to... Figure 9 .like Figure 9 As shown, the method may include:

[0244] S901: The third module obtains first information from the second module, the first information including memory change rate information.

[0245] As an example, the memory change rate information in this application embodiment includes, but is not limited to, one or more of the following: method time consumption, method popularity, number of objects created by the method, or number of applications applying the same method.

[0246] S902: The third module determines whether there is a method for the memory change rate to exceed the second threshold based on the first information. If yes, execute S904; otherwise, execute S903.

[0247] S903: PGO is not enabled in the third module.

[0248] S904: The third module records the method by which the memory change rate exceeds the second threshold, and determines whether the number of applications applying the method exceeds the third threshold based on the first information obtained. If yes, execute S905; otherwise, execute S903.

[0249] As an example, this embodiment only needs to record the method when the memory change rate is first detected to exceed the second threshold. When the method is detected again, since it has already been recorded, it is not necessary to record it again. It is only necessary to further determine the number of applications that apply the method, and so on.

[0250] As an example, embodiments of this application may record the method and the number of applications corresponding to the method in a memory or in a preset storage location, without limitation.

[0251] S905: Enable PGO in the third module.

[0252] As an example, after the optimized compilation of this method is completed in the embodiments of this application, the information such as the method and the number of applications that apply the method stored in the corresponding memory can be cleared.

[0253] It should be noted that when data collection is performed in this second scenario in the embodiments of this application, the data collection can be targeted, such as collecting only the memory change rate related information involved in the memory change rate scenario, i.e., incremental addition information; or, for example, all the information involved in the memory change rate scenario can be collected, i.e., completely re-collected, which is not limited here.

[0254] Application Example 3: PGO execution solution in a mixed AOT and JIT programming scenario.

[0255] During application operation, AOT compilation and JIT compilation are frequently involved. To better debug applications, this embodiment can determine whether PGO needs to be enabled based on JIT compilation status, and identify functions or applications requiring compilation optimization. For example, JIT is a common optimization compilation method. If a function executes JIT compilation too many times (i.e., high-frequency JIT compilation), it can be considered a "hot" function. Furthermore, the high frequency of JIT compilation indicates that the function is not included in AOT compilation, meaning it is ignored by AOT. In this case, this embodiment can enable PGO for that function and add it to AOT during PGO activation. For example, adding the function to the profile file for compilation optimization can achieve good results. Therefore, to improve system performance, reduce system overhead, and decrease the number of compilation operations, this embodiment can set targeted PGO enabling conditions based on the AOT and JIT mixed compilation scenario. Thus, PGO is enabled when the corresponding PGO enabling conditions are met in the AOT and JIT mixed compilation scenario. Furthermore, embodiments of this application can also set targeted PGO shutdown conditions based on the AOT and JIT hybrid programming scenario, thereby shutting down PGO when the corresponding PGO shutdown conditions are met in the AOT and JIT hybrid programming scenario. Through this solution, embodiments of this application can effectively avoid situations where PGO cannot be shut down after being enabled, or cannot be restarted after being shut down, effectively improving the flexibility of the system in executing PGO, making it more adaptable, and effectively reducing system overhead.

[0256] As an example, the enabling conditions for PGO set in this AOT and JIT hybrid programming scenario in the embodiments of this application include, but are not limited to, one or more of the following:

[0257] Content 1: The number of times a certain function is compiled by JIT exceeds the fourth threshold.

[0258] For example, in this mixed AOT and JIT compilation scenario, the condition for enabling PGO is that among the functions in the first information that perform JIT compilation, there is a function whose number of JIT compilations is greater than the fourth threshold.

[0259] Based on this memory change rate scenario, the compilation optimization method provided in this application embodiment can be referred to... Figure 10 .like Figure 10 As shown, the method may include:

[0260] S1001: The third module obtains first information from the second module. The first information includes information about functions that perform JIT compilation. In this embodiment of the application, the information about functions that perform JIT compilation includes, but is not limited to, functions that perform JIT compilation, the number of times the function performs JIT compilation, etc.

[0261] As an example, embodiments of this application can perform the acquisition of first information when it is determined that JIT compilation exists, thereby effectively determining the time to acquire the first information and reducing the overhead of acquiring information.

[0262] S1002: The third module executes the JIT compilation function for the first time based on the first information record.

[0263] As an example, in this embodiment of the application, when a function is first found to be performing JIT compilation, the function performing JIT compilation can be recorded and the number of times the function performs JIT compilation can be recorded as 1.

[0264] S1003: The third module determines whether the number of times a function that performs JIT compilation exceeds the fourth threshold. If yes, execute S1004; otherwise, execute S1005.

[0265] As an example, in this embodiment of the application, after a function that performs JIT compilation is recorded for the first time, when the function is detected to perform JIT compilation again, since the function has been recorded before, it is not necessary to record the function again. It is only necessary to further increment the number of times the function performs JIT compilation by 1, and so on.

[0266] As an example, embodiments of this application may record the method, the corresponding JIT compilation function, and the number of times JIT compilation is performed in memory, or in a preset storage location, without limitation.

[0267] S1004: The third module adds this function to AOT and enables PGO.

[0268] S1005: PGO is not enabled in the third module.

[0269] As an example, after the optimized compilation for this method is completed in the embodiments of this application, the information such as the function that performs JIT compilation and the number of times JIT compilation is performed stored in the corresponding memory can be cleared.

[0270] It should be noted that when data collection is performed in this application embodiment in scenario three, the data collection can be targeted, such as collecting only information related to JIT compilation functions involved in the mixed-programming scenario, i.e., incrementally adding information; or, for example, collecting all information involved in the mixed-programming scenario, i.e., completely re-collecting, which is not limited here.

[0271] Application Example 4: PGO execution scheme in a scenario where AOT and interpreter run in combination.

[0272] During application operation, hotspot function application scenarios are frequently encountered. To better debug applications, this embodiment can determine whether PGO needs to be enabled based on the status of hotspot functions, and identify functions or applications requiring compilation optimization. For example, this embodiment can record and update hotspot functions during interpreter execution. When the number of unoptimized hotspot functions is too high, the application is considered outdated and no longer suitable for current application needs; in this case, PGO can be enabled. Therefore, to better improve system performance, reduce system overhead, and enhance system performance, especially the application performance of hotspot functions, this embodiment can set targeted PGO enabling conditions based on the mixed AOT and interpreter operation scenario. PGO is enabled when the corresponding enabling conditions are met in this mixed AOT and interpreter operation scenario. Furthermore, this embodiment can also set targeted PGO disabling conditions based on the mixed AOT and interpreter operation scenario. PGO is disabled when the corresponding disabling conditions are met in this mixed AOT and interpreter operation scenario. With this solution, the embodiments of this application can effectively avoid situations such as PGO being unable to be closed after it is started, and PGO being unable to be started again after it is closed. This effectively improves the flexibility of the system in executing PGO, makes it more adaptable, and effectively reduces system overhead.

[0273] As an example, the activation conditions for PGO set in this AOT and interpreter hybrid operation scenario in the embodiments of this application include, but are not limited to, one or more of the following:

[0274] Content 1: There are unoptimized hotspot functions.

[0275] As an example, embodiments of this application can identify hot functions through an interpreter. For instance, during the execution of the interpreter, the hotness count of the current function is updated and recorded. When the hotness count exceeds the fifth threshold of the hot function, the function is recorded as a hot function.

[0276] As an example, the Hotness Count described above in this application embodiment can be understood as a counter used to track the number of times a code segment (such as a method or loop) is executed at runtime. The compiler or virtual machine uses this counter to determine which code segments are worth optimizing. When the hotness count of a code segment reaches a preset threshold, the compiler or virtual machine considers this code segment to be a "hot spot".

[0277] Content 2: The number of unoptimized hotspot functions exceeds the sixth threshold.

[0278] In some implementations, when the memory change rate of a certain method is determined to exceed a second threshold, the method and the number of applications using the method can be recorded to further determine whether the number of applications using the method exceeds a third threshold.

[0279] In this scenario where AOT and interpreter run in a hybrid environment, the activation condition for PGO can be any of the above-mentioned content 1 or content 2, or a combination of content 1 and content 2. For example, the activation condition for PGO in this scenario where AOT and interpreter run in a hybrid environment is that there are hot functions in the function execution information included in the first information, and the number of unoptimized hot functions exceeds the sixth threshold.

[0280] In this scenario of hybrid operation of AOT and interpreter, the compilation optimization method provided in this application embodiment can be referred to... Figure 11 .like Figure 11 As shown, the method may include:

[0281] S1101: The third module obtains first information from the second module. The first information includes function execution information. In this embodiment of the application, the function execution information includes, but is not limited to, hotnesscount corresponding to at least one function.

[0282] S1102: The third module determines whether there is a function whose hotness count corresponding to the at least one function exceeds the fifth threshold. If yes, execute S1103; otherwise, execute S1104.

[0283] S1103: The third module identifies functions whose hotness count exceeds the fifth threshold as hot functions, records the number of hot functions, and continues to execute S1105.

[0284] S1104: After the third module has run for the first duration, update the interpreter hotness count and continue executing S1102.

[0285] S1105: The third module determines whether the number of hot functions exceeds the sixth threshold. If yes, execute S1106; otherwise, execute S1104.

[0286] S1106: Enable PGO in the third module.

[0287] It should be noted that when data collection is performed in this application embodiment in scenario four, the data collection can be targeted. For example, only information related to the interpreter hotness count and hotspot functions involved in the mixed operation scenario of AOT and interpreter can be collected, i.e., incrementally adding information; or, all information involved in the mixed operation scenario of AOT and interpreter can be collected, i.e., completely re-collected, which is not limited here.

[0288] In some implementations, embodiments of this application also provide a compilation optimization method. This method can, in any of the aforementioned target scenarios, for example, enable PGO after determining that the enabling conditions for PGO are met in any of the aforementioned target scenarios; or, for another example, after PGO finishes running and is disabled in any of the aforementioned target scenarios, if the enabling conditions for PGO are met again in any subsequent target scenario, PGO can be enabled again. Figure 12 As shown, the method may include:

[0289] S1201: Obtain first information based on the operating information of the electronic device.

[0290] S1202: Determine that the first information meets the conditions for enabling PGO in the current target scenario, and enable PGO.

[0291] As an example, when different target scenarios can run in parallel, if multiple target scenarios in this application meet the conditions for PGO to be enabled, PGO can be enabled in parallel; or, if multiple target scenarios in this application meet the conditions for PGO to be enabled, PGO can be enabled sequentially based on different target scenarios, etc., without limitation.

[0292] S1203: Close PGO after it finishes running.

[0293] S1204: Obtain second information based on the operating information of the electronic device.

[0294] S1205: Determine whether the second information meets the conditions for enabling PGO in the current target scenario, and enable PGO.

[0295] As an example, the target scene described in step S1205 of this application embodiment may be the same target scene as the target scene described in step S1202 above, or it may be a different target scene, which is not limited here.

[0296] S1206: Close PGO after it finishes running.

[0297] In some implementations, embodiments of this application also provide a compilation optimization method, which can be applied to, but is not limited to, the system architecture described above, such as... Figure 13 As shown, the method may include:

[0298] S1301: Determine if the first application is in the whitelist. If yes, proceed to S1302; otherwise, proceed to S1303.

[0299] S1302: Determine whether there is AOT compilation information in the feedback file based on the first application. If yes, execute S1303; otherwise, execute S1304.

[0300] For example, in this application embodiment, a feedback file can refer to a file used to collect and record user or system feedback. This file may contain user evaluations, suggestions, problem reports, or system log files, etc., and is not limited thereto.

[0301] S1303: Do not enable PGO.

[0302] S1304: Determine whether the conditions for enabling PGO are met. If yes, proceed to S1305; otherwise, proceed to S1303.

[0303] As an example, this application embodiment can determine whether the PGO enabling conditions are met during AOT operation. The content of the PGO enabling conditions can be found in the description of the above embodiments, and will not be repeated here for the sake of brevity.

[0304] As an example, embodiments of this application may obtain first information based on a feedback file and determine whether the conditions for enabling PGO are met based on the first information.

[0305] S1305: Enable PGO.

[0306] S1306: Recompile AOT, and close PGO after compilation is complete.

[0307] In some implementations, enabling PGO as described in the above embodiments of this application can refer to enabling PGO acquisition to obtain more accurate acquisition data. For example, enabling PGO acquisition may include obtaining a profile file. Alternatively, it may refer to completing the entire PGO execution. For example, enabling PGO includes not only the data acquisition phase but also compilation optimization based on the acquired data. This is not limited here. Optionally, embodiments of this application can obtain a profile file by analyzing the application's runtime information using the system's built-in compiler toolchain or a dedicated performance analysis tool. Alternatively, a profile file can be obtained by analyzing the application's runtime information using a third-party performance analysis tool. The profile file may include various performance data and statistical information during program runtime, which can better guide the compiler to perform more efficient optimizations. This is not limited here.

[0308] It should be understood that the implementation processes provided in the above embodiments are merely illustrative examples of the applicable method processes in the embodiments of this application. The execution order of each step in each embodiment can be adjusted according to actual needs, and other steps can be added or some steps can be removed. The execution order between steps that are not temporally related in each embodiment can be arbitrary, and this application does not impose any restrictions on this.

[0309] The solutions provided in the above embodiments are illustrated using a scenario with a virtual machine and a processor as an example. However, it should be understood that the virtual machine and / or processor described in the solutions provided in the above embodiments may also have the functions of other solution examples. For example, the virtual machine and / or processor of a certain solution may be divided into multiple virtual modules and / or processing modules for implementation. Alternatively, the solutions provided in the embodiments of this application may also include other virtual machines and / or processors. The number of multiple virtual machines and / or processors is not specifically limited in the embodiments of this application.

[0310] Based on the above embodiments and the same technical concept, this application also provides an electronic device for implementing the compilation optimization method provided in this application for any device. Figure 14 As shown, electronic device 1400 may include: memory 1401, one or more processors 1402, and one or more computer programs (not shown). These devices may be coupled via one or more communication buses 1403. Optionally, electronic device 1400 may also include a display screen 1404.

[0311] The memory 1401 stores one or more computer programs (code), and the one or more computer programs include computer instructions; one or more processors 1402 call the computer instructions stored in the memory 1401, causing the electronic device 1400 to execute the compilation optimization method provided in the embodiments of this application.

[0312] In a specific implementation, memory 144401 may include high-speed random access memory and may also include non-volatile memory, such as one or more disk storage devices, flash memory devices, or other non-volatile solid-state storage devices. Memory 1401 may store an operating system (hereinafter referred to as the system), such as embedded operating systems like Android, iOS, Windows, or Linux. Memory 1401 can be used to store implementation programs of the embodiments of this application. Memory 1401 may also store network communication programs, which can be used to communicate with one or more additional devices, one or more user devices, or one or more network devices.

[0313] One or more processors 1402 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of programs according to the present application.

[0314] Display screen 1404 is used to display the PGO running interface and related information.

[0315] It should be noted that, Figure 14 This is merely one implementation of the electronic device 1400 provided in this application embodiment. In practical applications, the electronic device 1400 may include more or fewer components, as detailed in the following references. Figure 2 The specific structure and description shown are not limited here.

[0316] Based on the above embodiments and the same technical concept, this application also provides a computer-readable storage medium storing a computer program that, when run on a computer, causes the computer to perform the method provided in the above embodiments applicable to any scenario.

[0317] Based on the above embodiments and the same technical concept, this application also provides a computer program product, which includes a computer program or instructions. When the computer program or instructions are run on a computer, the computer performs the method provided in the above embodiments for any scenario.

[0318] The methods provided in this application can be implemented, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, they can be implemented, in whole or in part, in the form of a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of the present invention is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. A computer-readable storage medium can be any available medium that a computer can access, or a data storage device such as a server or data center that integrates one or more available media. Available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs), or semiconductor media (e.g., SSDs), etc.

[0319] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method of compiler optimization, characterized by, The method is applied to an electronic device, and the method includes: First information is obtained based on the operating information of the electronic device; In the target scenario, when the first information satisfies the conditions for enabling PGO and PGO is disabled, PGO is enabled. The target scenario includes deopt optimization scenario, memory change rate scenario, mixed pre-compiled AOT and just-in-time (JIT) compilation scenario, and mixed AOT and interpreter running scenario. When the PGO finishes running, close the PGO.

2. The method as described in claim 1, characterized in that, The first information includes any one or more of the following: Depot information, memory change rate information, JIT compiled function information, function execution information; The depot information includes one or more of the depot function and the number of depot operations; the memory change rate information includes one or more of the function execution time, function popularity, number of objects created by the function, or number of applications using the same function; the JIT compiled function information includes one or more of the functions that are executed by JIT compilation and the number of times the functions are executed by JIT compilation; and the function execution information includes popularity counts for at least one function.

3. The method of claim 2, wherein, The target scenario is a depot scenario, and the first information includes the depot information; or... The target scenario is a memory change rate scenario, and the first information includes the memory change rate information; or, The target scenario is a hybrid scenario of pre-compiled AOT and just-in-time (JIT) compilation, and the first information includes the function information compiled by JIT; or, The target scenario is a hybrid scenario of AOT and interpreter operation, and the first information includes the function execution information.

4. The method of claim 1, wherein, The conditions for activating PGO include any one or more of the following: The number of deopt updates exceeds a first threshold, which is the upper limit of the number of deopt updates; the deopt function comes from pre-compiled AOT; the deopt function comes from just-in-time (JIT) compilation; the memory change rate during function runtime exceeds a second threshold, which is the upper limit of the memory change rate during function runtime. The number of applications using functions whose memory change rate exceeds the second threshold exceeds the third threshold, where the third threshold is the upper limit of the number of applications; the number of times the same function is JIT compiled exceeds the fourth threshold, where the fourth threshold is the upper limit of the number of times JIT compilation is performed on the same function during JIT compilation; There are unoptimized hot functions, which include functions whose popularity count exceeds a fifth threshold, where the fifth threshold is the upper limit of popularity count for determining whether a function belongs to the hot functions; the number of unoptimized hot functions exceeds a sixth threshold, where the sixth threshold is the upper limit of the number of unoptimized hot functions.

5. The method of claim 4, wherein, The target scenario is a deopt scenario, and the first information satisfies the conditions for enabling PGO, including: The first information includes a first deopt function that comes only from AOT, and the number of deopt updates of the first deopt function exceeds the first threshold; or, The first information includes a first depot function that comes only from JIT, and the number of deopt updates of the first deopt function exceeds the first threshold; or, The first information includes a first depot function, part of which comes from AOT and another part from JIT, and the first depot function's depot update count exceeds the first threshold.

6. The method of claim 4, wherein, The target scenario is a memory change rate scenario, and the first information satisfies the PGO enabling conditions, including: The memory change rate of the first function included in the first information exceeds the second threshold; and / or, the number of applications of the first function exceeds the third threshold.

7. The method of claim 4, wherein, The target scenario is a hybrid AOT and JIT environment, and the first information satisfies the PGO enabling conditions, including: The first information includes functions that have been executed JIT compilation more than the fourth threshold.

8. The method of claim 4, wherein, The target scenario is a hybrid scenario of AOT and interpreter operation, and the first information satisfies the PGO enabling conditions, including: The first information includes function execution information containing hotspot functions, and the number of unoptimized hotspot functions exceeds the sixth threshold.

9. The method according to any one of claims 1 to 8, characterized in that, The method further includes: The second information is obtained based on the operating information of the electronic device; In the target scenario, when the second information satisfies the activation condition of the PGO and the PGO is closed, the PGO is activated. When the PGO finishes running, shut down the PGO.

10. The method according to any one of claims 1 to 9, characterized in that, The method further includes: Before enabling PGO, determine if some or all of the applications corresponding to the running information are in the whitelist; the whitelist includes a list of applications that are allowed to enable PGO.

11. An electronic device, comprising: The electronic device includes a memory and one or more processors; The memory is used to store computer program code, which includes computer instructions; when the computer instructions are executed by the one or more processors, the electronic device performs the method as described in any one of claims 1 to 10.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when run on an electronic device, causes the electronic device to perform the method as described in any one of claims 1 to 10.

13. A computer program product, characterised in that, The computer program product includes a computer program or instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1 to 10.

Images