Initial data distribution for different application processes

Abstract

In a mobile device, the process of an application can be monitored and scored for an initial data distribution. Specifically, a method can include monitoring the process of the application and scoring objects or components used by the process to determine the placement of the objects or components in memory during application startup. The method can also include at least partially loading the objects or components scored at a first level into a first portion of the memory during startup of the application. The method can also include at least partially loading the objects or components scored at a second level into a second portion of the memory during startup of the application. The objects or components scored at the second level can be less important to the application than the objects or components scored at the first level.

Description

[0001] Related Applications

[0002] This application claims priority to U.S. Patent Application No. 16 / 592,547, filed on October 3, 2019, and titled "INITIAL DATA DISTRIBUTION FOR DIFFERENT APPLICATION PROCESSES", the entire disclosure of which is hereby incorporated by reference herein. Technical Field

[0003] At least some embodiments disclosed herein relate to the root process of a computing system and to the initial data distribution for different application processes in a computing device. Background Art

[0004] The internal workings of the ANDROID operating system include the zygote, which acts as the parent or root process for all ANDROID application processes. In UNIX and UNIX-like operating systems (e.g., LINUX and ANDROID), any non-initial process (or any non-zero process) can originate, at least in part, from the initial or zero process of the operating system (OS). Thus, the ANDROID OS uses the term "zygote" to refer to its root process or process 0.

[0005] ANDROID is a mobile OS developed by GOOGLE for mobile devices. It is based on a modified version of the LINUX kernel and other open-source software and is primarily designed for mobile devices (e.g., smartphones, tablet computers, etc.). GOOGLE has also developed an ANDROID version for the Internet of Things (IoT). Moreover, ANDROID versions have been developed for televisions and other household appliances, in-vehicle infotainment systems, wearable smart devices, game consoles, digital cameras, and other types of electronics, including PCs.

[0006] When another process executes a system call represented by "fork()", ANDROID, UNIX, or another UNIX-like OS creates a non-zero process, which causes one process to fork into multiple processes. The process that calls the fork is the parent process, and the newly created process is the child process. In UNIX or UNIX-like operating systems, the kernel can identify each process by its process identifier. For example, "0" represents the initial process or zero process. In UNIX and similar operating systems, the zero process (i.e., process 0) is the root process that is generated when the OS starts. The first child process, called "init" (e.g., process 1), can originate, at least in part, from the zero process and can become the ancestor of all other processes in the OS. Brief Description of the Drawings

[0007] The present disclosure will be more fully understood in light of the detailed description given below and the accompanying drawings of various embodiments of the present disclosure.

[0008] Figure 1 、 4 and FIGS. 6 illustrate example mobile devices that can implement an initial data distribution for different application processes according to some embodiments of the present disclosure.

[0009] Figure 2 、 3 、5, 7, and 8 illustrate flowcharts of example operations that can be performed by the mobile devices depicted in FIGS. Figure 1 、 4 and 6 according to some embodiments of the present disclosure.

[0010] Figure 9 Illustrates an example computing device that can implement an initial data distribution for different application processes according to some embodiments of the present disclosure.

[0011] Figure 10 Illustrates, according to some embodiments of the present disclosure, Figure 1 、 4 and the example mobile devices depicted in 6, which include example alternatives for a root process. DETAILED DESCRIPTION

[0012] At least some embodiments disclosed herein relate to a root process of a computing system and to an initial data distribution for different application processes in a computing device.

[0013] Some embodiments disclosed herein relate to computing devices, such as mobile devices, having different types of memory (e.g., dynamic random access memory (DRAM), non-volatile random access memory (NVRAM), 3D XPoint memory, and flash memory). The operating system of the computing device can score different data objects and components of an application to determine where the objects and components are initially placed in the memory. The objects and components can be placed in different types of memory of the computing device, and the placement of the objects and components can occur when the application is initially launched.

[0014] An initial application process (e.g., the root process of an application) can have an executable file and any loadable modules and libraries for execution. These executable files and loadable modules and libraries can be loaded into the memory of the application process before the application process and during the root process of the application.

[0015] Some components (such as static components) may be pre-determined to be on the critical path and can thus be loaded into a higher-performance memory type such as DRAM or SRAM. Some components may be pre-determined to be loaded into a memory-mapped shared file for inter-process communication (IPC) and can thus be loaded into a higher-performance memory type such as DRAM or SRAM. Additionally, a higher-performance memory type may be explicitly allocated to more important processes, or a higher-performance shared memory region may be explicitly allocated to more important processes (e.g., via Anonymous Shared Memory (Ashmem) or Graphics Memory Allocator (Gralloc)). Some important user-triggered memory pages of significant size may be moved to a higher-performance memory type in the device. Important structures (such as those related to the application runtime environment and system calls) may also be allocated to a higher-performance memory type of the device.

[0016] The computing device can, for example, through the OS, score its components and objects during the execution of each application and store the scores in a score table (which can be part of the application itself). After the user has invoked the application multiple times, the scoring process (implemented, for example, via counting, training, and / or machine learning processes) can be used to improve the performance of the application. Optionally, the computing device can identify which objects are important and which are not important by having an initial score table.

[0017] By default, objects in an application process are shared between processes (e.g., after the root process forks). When there is a write to the object (e.g., a triggering event for copy-on-write (COW)), the object or a part of it can be moved and / or copied from its storage location to another memory type (e.g., from NVRAM to DRAM, or from DRAM to NVRAM, or from DRAM to SRAM), or moved and / or copied to the same memory type, depending on which bus has less occupancy (e.g., depending on the bandwidth of the DRAM bus or the NVRAM bus) or is expected to have less occupancy in the near future. The movement of a component or object can also depend on the degree to which the component or object (or a part of it) is expected to be used or the length of time it will remain in memory before being evicted.

[0018] The Expectation Maximization algorithm can be used to maximize the expected user experience measured by meaningful metrics (e.g., frames per second, touch-render response time, etc.), and at the same time maximize but not exceed the bus capacity resources of multiple memory types. A shared object can initially be placed in the highest performance type of memory (e.g., DRAM) in the device, and gradually be partially copied into that memory type and partially copied into a lower performance type of memory (e.g., NVRAM or flash memory). The gradual copying can be triggered by COW to be done part by part. And, after a period of time, if not frequently used, the part of the shared object in the highest performance type of memory (e.g., the part in DRAM) can be evicted to a lower performance type of memory (e.g., NVRAM or flash memory). Alternatively, the part in the highest performance type of memory can be directly copied as a whole to a lower performance type of memory, or the part can be moved back and forth between different types of memory with each write. The operating system can attempt to keep a set of user-important working objects (e.g., objects used by foreground applications and / or running processes in the background) in the highest performance type of memory in the computing device. Other objects can be migrated to a lower performance type of memory in the computing device, and some important parts of them are still cached in the higher performance type of memory.

[0019] Some embodiments disclosed herein relate to an OS or hypervisor, etc. of one or more computing devices, which are configured to monitor multiple processes of an application. The monitoring can be performed for a single computing device or for a group of devices. The OS, hypervisor, etc. can be configured to score objects or components used by the multiple processes to determine the placement of the objects or components in memory during application startup.

[0020] During the startup of an application, the OS, hypervisor, etc. can be configured to at least partially load objects or components scored at a first level into a first part of memory. Additionally, during the startup of an application, the OS, hypervisor, etc. can be configured to at least partially load objects or components scored at a second level into a second part of memory, where the objects or components scored at the second level are less important to the application than the objects or components scored at the first level. The first part of memory can include DRAM. The second part of memory can include NVRAM. The NVRAM can include 3DXPoint memory.

[0021] The startup of an application can include executing the root process of the application. At least in part, the OS, hypervisor, etc. can be configured to execute the root process of the application. The root process can include loading objects or components scored at a first level, and / or the root process can include loading objects or components scored at a second level.

[0022] In addition, in some embodiments, the startup of an application may include the startup of applications in an application group, and the startup may include executing the root process of the application group. At least in part, the OS, hypervisor, etc. may be configured to execute the root process of the application (or application group). The root process may include loading objects or components rated at a first level, and / or the root process may include loading objects or components rated at a second level.

[0023] In some embodiments, the OS, hypervisor, etc. may be configured to store the corresponding identifiers and ratings of the rated objects or components in a rating table. Additionally, the rating may be at least in part based on machine learning. In such embodiments, the OS, hypervisor, etc. may be configured to repeatedly monitor multiple processes, rate objects or components, and load objects or components. And with each repetition of monitoring, rating, and loading, the OS, hypervisor, etc. may be configured to train at least part of the rating of the objects or components. The rating may be at least in part based on an artificial neural network (ANN), and in such instances, the training may include training the ANN.

[0024] In some embodiments, the OS, hypervisor, etc. may be configured to move at least some of the objects or components from a first part of the memory to a second part of the memory when usage decreases or is predicted to decrease beyond a first threshold for at least some of the objects or components loaded in the first part. Such movement may occur after the application starts up. Additionally, the OS, hypervisor, etc. may be configured to move at least some of the objects or components from the second part of the memory to the first part of the memory when usage increases or is predicted to increase beyond a second threshold for at least some of the objects or components loaded in the second part. Such movement may also occur after the application starts up. Additionally, after the application starts up, the OS, hypervisor, etc. may be configured to remove at least some of the objects or components from the second part of the memory when usage decreases beyond a third threshold for at least some of the objects or components in the second part.

[0025] In some embodiments, the OS, hypervisor, etc. may be configured to launch an application, and launching the application includes the OS, hypervisor, etc. executing the root process of the application to an initial point according to a previous execution mode of the application. Additionally, the OS, hypervisor, etc. may be configured to launch the application when the application is part of an application group, and launching the application includes the OS, hypervisor, etc. executing the root process of the application (or executing the root process of the application group) to an initial point according to a previous execution mode of the application (or application group). Additionally, the OS, hypervisor, etc. may be configured to receive a request to launch an application from a user of the computing device, and after receiving the request to launch the application, launch the application in the computing device by using the root process of the application (or by using the root process of the application group).

[0026] In some embodiments, the OS, hypervisor, etc. may be configured to fork the root process of an application (or fork the root process of an application group) into multiple processes. In such embodiments, the OS, hypervisor, etc. may be configured to launch the application in the computing device by using at least one of the multiple processes according to the request to launch the application after receiving the request to launch the application. At least some of the multiple processes may be different from each other and / or different from the root process. Additionally, at least some of the multiple processes may initially be the same as each other and / or the same as the root process.

[0027] The root process for an application (or for a group of applications) can be started when starting the OS, hypervisor, etc. In some embodiments, if an application has not been used for a certain period of time, or if the application consumes too many system resources, such as CPU, GPU, memory, or other resources, the root process of the application (or the root process of the group of applications) can be terminated. In such embodiments, when the use of the application is expected, the OS, hypervisor, etc. can be configured to restart the root process according to the patterns identified in the monitoring of the application. The preference for a pattern can be based on the amount, frequency, and / or recency of the pattern, and any type of memory access pattern for the application can be monitored and tracked. The monitoring and tracking can include hardware and software performance counters, which can be used by the OS via reading and writing dedicated registers (e.g., model-specific registers). The pattern can be based on metrics (such as the amount, frequency, and / or recency of reads from memory, writes to memory), address patterns in physical memory space, address patterns in virtual space, data locality (spatially and / or temporally), bank conflicts, or CPU cycles per instruction. The pattern can also be based on metrics such as the amount, frequency, and / or recency of translation lookaside buffer (TLB) metrics, and other metrics available to the OS.

[0028] In some embodiments, after an application is installed in a computing device (e.g., a mobile device), the OS of the device or the associated hypervisor can pre-start the application to generate a root application process customized for the user. The pre-start can occur before the user requests the computing device to start the application. The application can be executed at least in part via the OS or hypervisor, etc. Thus, the pre-start process or the root process of the application is different from the root process of the OS. In such embodiments, the OS or hypervisor, etc. can move and / or copy data to set up the root process of the application. In some embodiments, the copying and / or moving of data can initially be done by the root process of the OS. This can occur, for example, by the root process of the application before any initial read or write of the application. In some embodiments, common code and read-only data (e.g., libraries, runtimes, drivers, memory pages) are not copied and / or moved by the root process of the OS or the corresponding root process of the application. In some embodiments, the code and data of the root process are not copied until the code and data are initially modified by the root process, another process, or the OS. In some embodiments, only the modified portions of the code and data are copied, while the unmodified portions remain common. In some embodiments, these portions can be identified by monitoring writes to memory pages, cache lines, or other elements of the file system sectors or computer-readable storage media.

[0029] Initial reads and writes can be stored or cached in memory for use via a respective root process, particularly for an application or an application group that includes the application. In some embodiments, the storage or caching can be done in a faster memory to accelerate initial reads and writes. The initial reads and writes can be managed, maintained, prioritized, etc. by the OS, hypervisor, etc. via the memory according to usage frequency, recency of use, etc.

[0030] A computing device (e.g., a mobile device) can monitor a user's frequent or recent use of an application to determine initial reads and writes to add to the root process of the application (or the root process of the application group). This can cause the OS, hypervisor, etc. to read from and / or write to the memory of the application. Data movement and / or copying due to initial writes can also be performed before the user requests the OS, hypervisor, etc. to launch the application.

[0031] After the OS, hypervisor, etc. forks a system-level root process, predicted initial reads and / or writes of an application can be used to customize the root process of the application or the root process of the group. In such instances, the customized root process of the application or group can be saved in persistent non-volatile memory (e.g., flash memory and / or NVRAM) for fast startup of the application.

[0032] When the user requests the OS, hypervisor, etc. to launch an application, the OS, hypervisor, etc. can use the pre-launch process of the application or application group (i.e., the root process of the application or application group), or a forked process from the pre-launch process to serve the user. A forked process from the root process of the application or the root process of the application group can be similar to or different from its parent root process.

[0033] Additionally, when the user terminates an application, the OS can fully or partially terminate the active processes of the application and / or the root process of the application or application group. In anticipation of the user running the application, the OS, hypervisor, etc. can restart the root process of the application or application group, which can be further customized based on the most recent and / or frequent user usage patterns of the application.

[0034] Figure 1 、 4 and 6 illustrate an example mobile device 102 that can implement initial data distribution of different application processes according to some embodiments of the present disclosure. Additionally, as shown in Figure 4 and 6 According to some embodiments of the present disclosure, the mobile device 102 can include and run the respective root processes of multiple applications. For the purposes of the present disclosure, it should be understood that although Figure 1 、 40 and 6 involve a root process for each application, but such an application can be part of an application group, and the root process can be the root process of the application group.

[0035] Figure 2 , 3 , 5, 7, and 8 illustrate flowcharts of example methods 200, 300, 500, 700, and 800 that can be performed by the mobile device 102 depicted in Figure 1 , 4 0 and 6.

[0036] Specifically, Figure 1 illustrates the mobile device 102 that includes at least the memory 104. Figure 1 The memory 104 is also shown to include separate memory portions (e.g., refer to the first memory portion 106a, the second memory portion 106b, and the Nth memory portion 106c). Each separate memory portion can include a corresponding level of objects and / or components (e.g., refer to the first-level objects or components 108a, the second-level objects or components 108b, and the Nth-level objects or components 108c). The corresponding level can be associated with the importance or criticality of the execution of the corresponding application. In other words, each separate memory portion can include a corresponding level of objects and / or components, where the corresponding level relates to the importance or criticality of the objects and / or components for the execution of the application. Additionally, it should be understood by way of illustration that there can be more than two (or more than three) memory portions for a corresponding number of levels of objects and / or components in the memory 104 of the mobile device 102.

[0037] The OS in the mobile device 102, or a hypervisor in or communicatively coupled to the mobile device, etc., can be configured to monitor multiple processes of applications contained and executable in the mobile device. The OS, hypervisor, etc. can be configured to score objects or components used by the multiple processes (e.g., see the first-level object or component 108a, the second-level object or component 108b, and the N-level object or component 108c) to determine the placement of the objects or components in memory during application startup (e.g., see the memory 104). During the startup of an application, the OS, hypervisor, etc. can be configured to at least partially load the objects or components scored as the first level (e.g., see the first-level object or component 108a) into the first portion of the memory (e.g., see the first memory portion 106a). Additionally, during the startup of an application, the OS, hypervisor, etc. can be configured to at least partially load the objects or components scored as the second level (e.g., see the second-level object or component 108b) into the second portion of the memory (e.g., see the second memory portion 106b). The objects or components scored as the second level can be less important to the application than the objects or components scored as the first level.

[0038] Each memory portion can be composed of one or more types of memory. Also, each memory portion can provide different functions or trade-offs. For example, the first memory portion 106a or the highest memory portion can provide the highest performance in terms of the read and write speeds of the individual memory portions. The second memory portion 106b or the second-highest memory portion can provide the second-highest performance in terms of the read and write speeds of the individual memory portions. The lowest memory portion (e.g., see the N memory portion 106c) can provide the lowest performance in terms of the read and write speeds of the individual memory portions. However, as a trade-off, the lowest memory portion can provide the largest memory capacity, data reliability, availability, or persistence. To provide such functions, the first memory portion 106a or the highest memory portion can include DRAM or SRAM, or a combination of NVRAM and DRAM. Additionally, in such instances, the second memory portion 106b or the second-highest memory portion can include NVRAM, or a combination of DRAM, NVRAM, and / or flash memory. And, in such instances, the lowest memory portion (e.g., see the N memory portion 106c) can include flash memory, or a combination of NVRAM and / or flash memory. In all instances disclosed herein, the NVRAM can include 3D XPoint memory.

[0039] The startup of an application (e.g., see Figure 4 the applications 406a, 406b, and 406c shown therein) can include executing the root process of the application (e.g., see Figure 4The root processes 408, 412, and 416 shown in []. At least in part, the OS, hypervisor, etc. can be configured to execute the root processes of the application. The root processes can include loading objects or components scored at one or more levels. For example, the root processes can include loading objects or components scored at a first level (e.g., see the first-level object or component 108a), and / or the root processes can include loading objects or components scored at a second level (e.g., see the second-level object or component 108b).

[0040] In some embodiments, the OS, hypervisor, etc. can be configured to store the corresponding identities and scores of the scored objects or components (e.g., see the first-level object or component 108a, the second-level object or component 108b, and the N-level object or component 108c) in a score table (e.g., see Figure 1 the score table 110 shown in []).

[0041] In some embodiments, the score table 110 can be part of the application binary of the OS of the mobile device 102. In such embodiments, the score table is available to the user whenever the user updates the OS of the mobile device 102. Additionally, the score table 110 can be synchronized with the user's other devices via the cloud.

[0042] Additionally, the scoring can be at least partially based on machine learning. In such embodiments, the OS, hypervisor, etc. can be configured to repeatedly monitor multiple processes, score objects or components, and load objects or components. And with each repetition of monitoring, scoring, and loading, the OS, hypervisor, etc. can be configured to train at least part of the scoring of the objects or components. The scoring can be at least partially based on an ANN, and in such instances, the training can include training the ANN.

[0043] In some embodiments, the OS, hypervisor, etc. may be configured to move at least some objects or components from a first portion of the memory to a second portion of the memory when usage decreases or is predicted to decrease beyond a first threshold for at least some of the objects or components loaded in the first portion (e.g., when usage decreases or is predicted to decrease beyond the first threshold for at least some of the objects or components loaded in the first memory portion 106a, the objects or components in the first memory portion 106a may be moved to the second memory portion 106b). Such movement may occur after the application is launched. Additionally, the OS, hypervisor, etc. may be configured to move at least some objects or components from the second portion of the memory to the first portion of the memory when usage increases or is predicted to increase beyond a second threshold for at least some of the objects or components loaded in the second portion (e.g., when usage increases or is predicted to increase beyond the second threshold for at least some of the objects or components loaded in the second memory portion 106b, the objects or components in the second memory portion 106b may be moved to the first memory portion 106a). Such movement may also occur after the application is launched. Additionally, after the application is launched, the OS, hypervisor, etc. may be configured to remove at least some of the objects or components from the second portion of the memory or the lower or lowest portion of the memory (e.g., referring to the Nth memory portion 106c) when usage decreases beyond a third threshold for at least some of the objects or components in the second portion, lower portion, or lowest portion of the memory (depending on the embodiment).

[0044] Specifically, Figure 2 illustrates operations of a method 200 that may be performed by the mobile device 102 depicted in Figure 1 or by another type of computing device configured similar to the mobile device 102. Additionally, in some embodiments, the method 200 may be performed at least in part by the OS of a general computing device or the OS of a mobile device. The method 200 may also be performed at least in part by a hypervisor and / or one or more operating systems.

[0045] In Figure 2 , the method 200 begins at step 202 by monitoring multiple processes of an application. For example, step 202 may include monitoring multiple processes of an application in a computing device (e.g., a mobile device).

[0046] At step 204, the method 200 continues by scoring the objects or components used by the multiple processes to determine the placement of the objects or components in memory during application startup. For example, step 204 may include scoring the objects or components used by the multiple processes in a computing device to determine the placement of the objects or components in memory during application startup.

[0047] The scoring in step 204 can be at least partially based on machine learning. In such embodiments, the OS, hypervisor, etc. can be configured to repeatedly monitor multiple processes, score objects or components, and load objects or components. And, with each repetition of monitoring, scoring, and loading, the OS, hypervisor, etc. can be configured to train at least part of the scoring of the object or component (e.g., see step 214 of method 200). The scoring in step 204 can be at least partially based on an ANN, and in such instances, the training can include training the ANN in step 214.

[0048] In step 206, method 200 continues to store the corresponding identification and score of the scored object or component in a score table. For example, step 206 can include storing the corresponding identification and score of the scored object or component, and the storing can occur in a score table implemented in the memory of a computing device (e.g., a score table implemented in the memory of a mobile device).

[0049] In step 208, the method continues to start an application. Starting the application can include executing the root process of the application. The root process can include loading objects or components scored at a first level (e.g., the highest criticality level) and / or a second level (e.g., a criticality level lower than the highest level). In some embodiments, the monitoring in step 202 and the scoring in step 204 can be part of starting the application in step 208 (not depicted).

[0050] During application startup, the method continues to execute the root process of the application in step 210. Additionally, during application startup, the method continues to at least partially load the scored object or component into a portion of the memory in step 212 based on the score of the scored object or component. An object or component scored at the second level in step 204 can be less important to the application than an object or component scored at the first level in step 204.

[0051] In some embodiments, for example, in step 210, method 200 can include loading, via the root process, objects or components scored at a first level (e.g., the highest criticality level). Additionally, in step 210, method 200 can include loading, via the root process, objects or components scored at a second level (e.g., a criticality level lower than the highest level).

[0052] In some embodiments, for example, at step 212, method 200 may include loading at least partially an object or component scored at a first level (e.g., the highest criticality level) into a first portion of the memory (e.g., the memory portion of the highest performance level). Additionally, at step 212, method 200 may include loading at least partially an object or component scored at a second level (e.g., a criticality level lower than the highest level) into a second portion of the memory (e.g., a memory portion lower than the highest performance level). The first portion of the memory and the second portion of the memory may be constituted by one or more types of memories that may have different functions or trade-offs. For example, the first portion may provide the highest performance in terms of the read and write speeds of the individual memory portions. The second portion may provide the second highest performance in terms of the read and write speeds of the individual memory portions. However, as a trade-off, the second portion may provide a larger memory capacity, data reliability, availability, or persistence than the first portion. For example, in some embodiments, the first portion of the memory may include DRAM, and the second portion of the memory may include NVRAM. The NVRAM may include 3D XPoint memory.

[0053] As Figure 2 shown, method 200 may repeat itself after starting an application at step 208. For example, method 200 may include repeating the monitoring of multiple processes, the scoring of objects or components, and the loading of objects or components during the startup of the application. At step 214, method 200 continues to use each repetition of steps 202 to 212 to train at least a portion of the scoring of the objects or components at step 204. For example, with each repetition of the monitoring, scoring, and loading, method 200 may continue to train at least a portion of the scoring of the objects or components at step 214. In some embodiments, the scoring at step 204 may be at least partially based on an ANN, and the training may include training the ANN at step 214. In some embodiments, at least some of the steps may be repeated concurrently with other steps. For example, step 202 may be implemented to repeat itself continuously and may stream its output data into step 204, which is also implemented to repeat itself continuously, and so on. Due to such embodiments, method 200 may be implemented as a persistent execution pipeline.

[0054] Specifically, Figure 3 illustrates the operations of method 300 that may be performed by Figure 1 the mobile device 102 depicted in or by another type of computing device configured similarly to the mobile device 102. Additionally, in some embodiments, method 300 may be performed at least partially by the OS of a general computing device or the OS of a mobile device. Method 300 may also be performed at least partially by a hypervisor and / or one or more operating systems.

[0055] In Figure 3In [the above], method 300 starts at step 202 of method 200, monitoring multiple processes of an application. Then, at step 204 of method 200, method 300 continues to score an object or component used by the multiple processes to determine the placement of the object or component in memory during application startup. Then, at step 206 of method 200, method 300 continues to store the corresponding identifier and score of the scored object or component in a score table. Then, at step 208 of method 200, method 300 continues to start the application. During application startup, method 300 also continues to execute the root process of the application at step 210. Additionally, during application startup, method 300 continues to load the scored object or component into a portion of memory at least partially based on the score of the scored object or component at step 212.

[0056] At step 302, method 300 continues to move at least some of the objects or components from a higher portion of memory to a lower portion of memory when usage decreases or is predicted to decrease and exceeds a threshold for at least some of the objects or components loaded in the higher portion. At step 304, method 300 continues to move at least some of the objects or components from a lower portion of memory to a higher portion of memory when usage increases or is predicted to increase and exceeds a threshold for at least some of the objects or components loaded in the lower portion. At step 306, method 300 continues to remove at least some of the objects or components from the lower portion of memory mentioned in step 304 when usage decreases and exceeds a second threshold for at least some of the objects or components in the lower portion.

[0057] At step 308, method 300 continues to train at least part of the scoring of the object or component at step 204 using each repetition of steps 202 to 212 and steps 302 to 306. It should be understood that at least some of the repetitions of the steps can be performed concurrently with other steps. For example, steps 302 and 304 can be implemented to repeat continuously, and so on. Due to such embodiments, method 300 can be implemented as a persistent execution pipeline.

[0058] Some embodiments disclosed herein relate to a computing device having different types of memory (e.g., DRAM, NVRAM, 3DXPoint memory, and flash memory), such as a mobile device, e.g., see Figure 1 mobile device 102 and its different memory portions 106a, 106b, and 106c shown in [the reference]. The operating system of the computing device or another system in the device can score different data objects and components of an application (e.g., see Figure 1 objects or components 108a, 108b, and 108c shown in [the reference]) to determine the initial placement of the objects and components in memory, e.g., see Figure 2 and3 Step 204 shown in. Objects and components can be placed in different types of memories of a computing device, and the placement of the objects and components can occur when the application is initially started. For example, see Figure 2 and 3 Steps 208 to 212 shown in.

[0059] The initial application process (e.g., the root process of the application) can have executable files and any loadable modules and libraries for execution. These executable files and loadable modules and libraries can be loaded into the memory of the application process before the application process and during the root process of the application. For example, see Figure 2 and 3 Steps 208 to 212 shown in.

[0060] Some components (e.g., static components) can be scheduled to be on the critical path and thus can be loaded into a higher-performance memory type such as DRAM, which can be included in steps 204 and 212 respectively. Some components can be scheduled to be loaded into a memory-mapped shared file for inter-process communication (IPC) and thus loaded into a higher-performance memory type such as DRAM, which can be included in steps 204 and 212 respectively. Additionally, a higher-performance memory type can be explicitly allocated to a more important process, or a higher-performance shared memory region can be explicitly allocated to a more important process (e.g., via Anonymous Shared Memory (Ashmem) or Graphics Memory Allocator (Gralloc)), which can be included in step 204, for example. Some important user-triggered memory pages of significant size may be transferred to a higher-performance memory type in the device. Important structures (e.g., related to the application runtime environment and system calls) may also be allocated to a higher-performance memory type of the device, which can be included in step 204, for example.

[0061] The computing device can score its components and objects during the execution of each application, e.g., via the OS, etc., and store the scores in a score table (which can be part of the application itself), e.g., see steps 204 and 206. After the user calls the application multiple times, the scoring process (implemented, e.g., via counting, training, and / or machine learning processes) can be used to improve the performance of the application, e.g., see steps 214 and 308. Optionally, the computing device can identify which objects are important and which are not important by having an initial score table.

[0062] By default, objects in an application process are shared between processes (e.g., after the root process forks). At step 302 or 304, when there is a write to the object (e.g., a trigger event for copy-on-write (COW)), the object or a part of it can be moved and / or copied from where it is stored to another memory type (e.g., moved and / or copied from NVRAM to DRAM, or from DRAM to NVRAM), or moved and / or copied to the same memory type, depending on which bus is less utilized (e.g., depending on the bandwidth of the DRAM bus or the NVRAM bus) or is expected to be less utilized in the near future. The movement of components or objects at steps 302 and 304 can also depend on the degree to which the component or object (or a part of it) is expected to be used or the length of time it will remain in memory before being evicted.

[0063] In some embodiments, intelligent COW can be used from the root process to the application process. The implementation of intelligent COW can be a function of inputs including current and predicted memory bus traffic, object usage, predicted time before COW is no longer valid, and can be sensed by user metrics (e.g., frames per second, screen response, etc.). Intelligent COW can be improved via the expectation-maximization algorithm, which uses inputs such as current and predicted memory bus traffic, object usage amounts, predicted time, and user-related metrics.

[0064] At step 204, the expectation-maximization algorithm can be used to maximize the expected user experience measured by meaningful metrics (e.g., frames per second, touch-render response time, etc.), and at the same time maximize the bus capacity resources of multiple memory types.

[0065] At step 302, a shared object can initially be placed in the highest-performance type of memory in the device (e.g., DRAM), and gradually be partially copied into that memory type and partially copied into a lower-performance type of memory (e.g., NVRAM or flash memory). The gradual copying can be triggered by COW on a per-part basis. And over time, if not used frequently, the part of the shared object in the highest-performance type of memory (e.g., the part in DRAM) can be evicted to a lower-performance type of memory (e.g., NVRAM or flash memory). Or the part in the highest-performance type of memory can be directly copied as a whole to a lower-performance type of memory, or the part can be moved back and forth between different types of memory, for example, with each write between steps 302 and 304.

[0066] The round-trip between different types of memories may include ping-ponging between different types of memories. The ping-ponging can be or include advanced algorithms where portions of an object are copied or moved from one memory portion or type to another memory portion or type. For example, a new process can be forked and its writes to a shared object in some portions. Assume that memory bus A is busy and bus B is idle. The read-modify-write to the portion of the object can then be moved from memory A to memory B via ping-ponging. Additionally, in the case where portions of its object are in memory B, another process can be forked from one process. And, assume that memory bus A is busy and bus B is idle. The read-modify-write to the portion of the object can then be moved from one portion of memory B back to the same portion or another portion of memory B. If memory bus B is busy and bus A is idle, the read-modify-write to the portion of the object can be moved from memory B to memory A.

[0067] The operating system may attempt to keep a set of user-important working objects (e.g., objects used by foreground applications and / or running processes in the background) in the highest performance type of memory in the computing device. Other objects may be migrated to lower performance type memories in the computing device, and some important portions of them are still cached in the highest performance type of memory.

[0068] In some embodiments, the OS (or hypervisor, etc.) may be configured to launch an application, and the launch of the application includes executing the root process of the application to an initial point according to the previous execution mode of the application. Additionally, the OS (or hypervisor, etc.) may be configured to receive a request to launch an application from a user of the computing device, and upon receiving the request to launch the application, launch the application in the computing device by using the root process of the application.

[0069] Specifically, Figure 4 describe a mobile device 102 including at least a controller and a memory 404, which can implement creating a customized root process for an individual application or a group of applications. The memory of the controller and the memory 404 may include Figure 1The memory 104 shown in. The controller and memory 404 of the mobile device 102 may include instructions and data for applications (e.g., see applications 406a, 406b, and 406c) to be executed in the mobile device. The controller of the mobile device 102 may execute the instructions of the applications based on the data. The data may include application instruction codes in binary format or in a format suitable for interpretation by a programming language interpreter. The data may include some data structures, libraries, etc. The controller may also hold the instructions and data in the registers of the controller. The memory may hold the instructions and data in its memory cells. In some embodiments, the memory cells of the memory of the mobile device 102 may include flash memory cells and / or NVRAM cells. The NVRAM cells may be or include 3D XPoint memory cells.

[0070] In some embodiments, the memory may have different speeds, latencies, bandwidths, and other parameters. For example, SRAM memory may be used as a cache, DRAM may be used as main memory, and NVRAM may be used as storage memory.

[0071] The instructions and data for each application included and executable in the mobile device 102 may include root process data and instructions for the root process of the application. The respective root processes (e.g., see root process 408 of application 406a, root process 412 of application 406b, and root process 416 of application 406c) of the applications included in the mobile device 102 may be implemented by the controller and memory 404. The controller may be configured to execute the instructions of the root process according to the instructions and data for the root process, and the memory may be configured to hold or store the instructions and data for the controller to execute the root process.

[0072] In Figure 4 and 6 it is shown that the root process corresponds to a single application (e.g., see root process 408 and corresponding application 406a and root process 608 and corresponding application 606a). It should be understood that the root process may fork into multiple processes that may be used by a single application or by multiple applications including the single application. For example, if a single application is in an application group, the root process of the group may fork into multiple forked processes and the multiple forked processes may be used by the applications in the group. Additionally, a single application in an application group may use multiple different forked processes. For example, application 606a (which may be part of an application group) may use forked processes 610a, 610b, and 610c. It should be noted that Figure 6Other applications in the group with application 606a are not depicted. Additionally, as mentioned, multiple applications in the group may use multiple different forked processes. For example, applications 606a, 606b, and 606c may use forked processes 610a, 610b, and 610c (not depicted in Figure 6 ), for example, when the applications are in the same group. Such embodiments may be implemented by combining the forks. Figure 6 not depicted in Figure 6

[0073] In some embodiments, the initial execution of the forked root process may be limited to preloading libraries, composing the forked process from required libraries and initial data structures, and saving the forked process for further reuse. Additionally, at any time, the execution of the forked process may be saved in memory in a certain state such that the forked process can be reused to avoid spending time re - executing the process.

[0074] For the purposes of this disclosure, it should be understood that although Figure 1 and 4 and 6 refer to one root process per application, such applications can be part of an application group, and the root process can be the root process of the application group.

[0075] Other processes of the applications included in mobile device 102 (e.g., see applications 406a, 406b, and 406c) can also be implemented by controller and memory 404. The controller can be configured to execute the instructions of the other processes of the application according to the instructions and data for the other processes, and the memory can be configured to hold or store the instructions and data for the controller to execute the other processes.

[0076] Specifically, Figure 5 illustrates the operations of method 500 that can be performed by mobile device 102 depicted in Figure 1 and 4 and 6 or by another type of computing device configured similar to mobile device 102. Additionally, in some embodiments, method 500 can be performed at least in part by the OS of a general computing device or the OS of a mobile device. Method 500 can also be performed at least in part by a hypervisor and / or one or more operating systems.

[0077] In Figure 5 , method 500 starts at step 502, monitoring the usage of an application to determine the frequency or recency of reads from and writes to the memory for the application. In some embodiments (not depicted), method 500 can start monitoring and / or tracking the usage of an application to determine the amount, frequency, and / or recency of the previous execution pattern of the application.

[0078] A previous execution pattern of an application may include, relate to, or be based at least in part on the amount, frequency, and / or recency of patterns in a previous execution of the monitored and / or traced application. The monitored and / or traced patterns may be any type of application usage pattern of a user or machine. By way of example, any type of memory access and usage pattern of an application may be monitored and / or traced. A pattern may include, relate to, or be based on metrics (such as the amount, frequency, and / or recency of reads from memory, writes to memory), address patterns in physical memory space, address patterns in virtual space, data locality (spatially and / or temporally), bank conflicts, CPU cycles per instruction, and the like.

[0079] Additionally, monitoring and tracing the usage of an application may occur during application startup (e.g., including when the application is loaded into memory) and / or after the application is running. Monitoring and tracing the usage of an application may occur during application startup and during any other period after startup while the application is running. Monitoring and tracing the usage of an application during runtime may facilitate the derivation of an effective and / or efficient root process of the application. By way of example, after startup, a user may touch the screen to trigger some elements of the application and expect a certain result. In some embodiments, the delivery of the result may be very fast because important memory objects may be pre-loaded based on monitoring that occurs during the runtime of the application. In some embodiments, the pre-loading of objects may be done from a slower memory such as a NAND-type flash memory to a faster memory such as DRAM.

[0080] In step 504, method 500 continues to generate the previous execution pattern of the application based on the frequency or recency of reads from and writes to the memory for the application. In some embodiments (not depicted), method 500 may continue to generate the previous execution pattern of the application based on the amount, frequency, and / or recency of patterns in a previous execution of the monitored and / or traced application.

[0081] Additionally, the previous execution pattern of the generated application may at least include, relate to, or be based on the amount, frequency, and / or recency of patterns in the previous execution of the monitored and / or tracked application. The pattern generated in step 504 can be any type of application usage pattern of the user or the machine. For example, the pattern generated in step 504 may include any type of memory access pattern, and the usage of the application can be monitored and / or tracked. Additionally, for example, the generated pattern may include, relate to, or be based on metrics (such as the amount, frequency, and / or recency of reads from memory, writes to memory), address patterns in physical memory space, address patterns in virtual space, data locality (spatially and / or temporally), bank conflicts, or any other type of metric related to the usage of the application and the application's memory.

[0082] In step 506, method 500 continues to execute the root process of the application to an initial point according to the previous execution pattern of the application. Step 506 may include customizing the root process of the application according to the previous execution pattern of the application, and then executing the root process of the application to the initial point according to the previous execution pattern of the application. Step 506 may also include Figure 2 step 210 shown in Figure 2 step 212 and step 208 shown in

[0083] Customizing the root process can be completed, but is not limited to composing the root process from various libraries, using other root processes that are available by default, forming data structures, and querying various sources of root process components through the network.

[0084] The previous execution pattern of the application may at least include, relate to, or be based on the amount, frequency, and / or recency of patterns in the previous execution of the monitored and / or tracked application. The monitored and / or tracked pattern can be any type of application usage pattern of the user or the machine. For example, any type of memory access and usage pattern of the application can be monitored and / or tracked. The previous execution pattern of the application may include, relate to, or be based on metrics, at least such as the amount, frequency, and / or recency of any type of application usage pattern of the user or the machine. For example, the pattern may include, relate to, or be based on metrics (such as the amount, frequency, and / or recency of reads from memory, writes to memory), address patterns in physical memory space, address patterns in virtual space, data locality (spatially and / or temporally), bank conflicts, CPU cycles per instruction, etc.

[0085] The root process that executes the application may include moving data in the memory before any initial writes to and / or reads from the memory of the application. Additionally, the root process that executes the application may include copying data in the memory before any initial writes to and / or reads from the memory of the application. And, the data that is moved and / or copied may include data related to a previous execution pattern of the application. In some embodiments, moving and / or copying data in the memory before any initial writes to the memory may include avoiding moving and / or copying common code and read-only data. In some embodiments, method 500 may include, after the OS (or hypervisor) in the computing device forks the root process for the OS (or hypervisor), performing predicted initial writes and / or reads for the application to customize the execution of the root process of the application such that the root process of the application is an application-level process for the application.

[0086] Additionally, method 500 may include storing data for the root process of the application in a flash memory (not depicted in the figure) before at least partially executing the root process. Method 500 may also include storing data for the root process of the application in NVRAM (not depicted in the figure) before at least partially executing the root process. The NVRAM may include 3DXPoint memory. In some embodiments, storing new data may overwrite old unused data related to the use of the application.

[0087] In step 508, method 500 continues to receive a request from the user to start the application. In step 510, method 500 continues to start the application by using the root process of the application after receiving the request to start the application. In some embodiments, method 500 may include executing the root process of the application as a background process at least in part by the OS in the computing device according to a previous execution pattern of the application. In such embodiments, method 500 may also include receiving a request from the user of the computing device to start the application by the OS. And, method 500 may include starting the application in the computing device by the OS after receiving the request to start the application by using the root process of the application or a forked process of the root process. In some embodiments, the code and data of the forked process are not copied until the code and data are initially modified by the application, another process, or the OS. In some embodiments, only the modified portions of the code and data are copied, while the unmodified portions remain common. In some embodiments, such portions may be identified by monitoring writes to memory pages, cache lines, or file system sectors or other elements of a computer-readable storage medium.

[0088] In some embodiments, executing a root process to an initial point can be completed on one device, such as in a cloud computing environment, and then the root process is forked after receiving a request to start at least one of the applications from another device, and then the forked process is transmitted over a network to another device such as a mobile device, and then the forked process on the mobile device is used as a starting point for the application.

[0089] Specifically, Figure 6 a mobile device 102 including at least a controller and a memory 404 is described, and the memory of the controller and the memory 404 may include Figure 1 the memory 104 shown in. The controller and the memory 404 of the mobile device 102 may include instructions and data for applications (e.g., see applications 606a, 606b, and 606c) to be executed in the mobile device. The controller of the mobile device 102 may execute the instructions of the application based on the data. The data may include application instruction codes in binary format or in a format suitable for interpretation by a programming language interpreter. The data may include some data structures, libraries, etc. The controller may also hold the instructions and data in the registers of the controller. The memory may hold the instructions and data in its memory cells. In some embodiments, the memory cells of the memory of the mobile device 102 may include flash memory cells and / or NVRAM cells. The NVRAM cells may be or include 3D XPoint memory cells.

[0090] Also as Figure 6 shown, the instructions and data for each application included and executable in the mobile device 102 may include root process data and instructions for the root process of the application. As Figure 6 shown, the root processes of the applications included in the mobile device 102, e.g., see corresponding root processes 608, 612, and 616, may be implemented by the controller and the memory 404. The controller is configured to execute the instructions of the root process according to the instructions and data for the root process, and the memory is configured to hold or store the instructions and data for the controller to execute the root process. Additionally, as Figure 6 illustrated, other processes of the applications included in the mobile device 102 (e.g., see applications 606a, 606b, and 606c) may also be implemented by the controller and the memory 404. The controller is configured to execute the instructions of the other processes of the application according to the instructions and data for the other processes, and the memory is configured to hold or store the instructions and data for the controller to execute the other processes.

[0091] Additionally, as Figure 6As shown, the controller and the memory 404 may include data and instructions for a respective root process fork of the applications stored and executable in the mobile device 102 (e.g., see forked processes 610a, 610b, 610c, 614a, 614b, 618a, and 618b). As Figure 6 shown, at least processes 610a, 610b, and 610c fork from the root process 608; however, there may be more processes that fork from the root process 608. Processes 614a and 614b that fork from the root process 612 are also shown. And, processes 618a and 618b fork from the root process 616.

[0092] In some embodiments, the operating system of the mobile device 102 or the hypervisor in or associated with the mobile device is configured to fork the root process of an application (e.g., see the root process 608 of the application 606a, the root process 612 of the application 606b, and the root process 616 of the application 606c) into a plurality of processes (e.g., see forked processes 610a, 610b, 610c, 614a, 614b, 618a, and 618b). In such embodiments, the operating system or the hypervisor may be configured to start an application in the mobile device 102 in response to a request to start the application by using at least one of the plurality of forked processes (e.g., see forked processes 610a, 610b, 610c, 614a, 614b, 618a, and 618b) and / or the respective root process (e.g., see the root process 608 of the application 606a, the root process 612 of the application 606b, and the root process 616 of the application 606c) according to the request to start the application.

[0093] At least some or each of the plurality of forked processes may be different from the parent root process of the application. The differences may be based on different applications and different parts of the applications to be run in the computing device. And, at least at some point during the execution of the application, at least some or each of the plurality of forked processes may be the same as the parent root process of the application.

[0094] For the purposes of the present disclosure, it should be understood that although Figure 1 、 4 and 6 relate to one root process per application, such applications may be part of an application group, and the root process may be the root process of the application group.

[0095] Specifically, Figure 7 illustrates that it can be performed by Figure 6Operations of method 700 performed by the mobile device 102 depicted in or by another type of computing device configured similarly to the mobile device 102. Additionally, in some embodiments, method 700 may be performed by an operating system of a computing device generally or an operating system of a mobile device. Method 700 may also be performed by a hypervisor and / or one or more operating systems.

[0096] In Figure 7 method 700 begins with steps 502 through 508 of method 500 shown in more detail in Figure 5 At step 502, method 700 includes monitoring usage of an application to determine a frequency or recency of reads from and writes to a memory for the application. At step 504, the method includes generating a previous execution pattern of the application based on the frequency or recency of reads from and writes to the memory for the application. At step 506, the method includes executing a root process of the application to an initial point based on the previous execution pattern of the application. At step 508, the method includes receiving a request from a user to launch the application.

[0097] At step 702, method 700 continues to fork a root process of the application into multiple processes. At step 704, method 700 continues to launch the application in response to a request to launch the application by using at least one of the multiple processes. Alternatively, at step 702, method 700 may continue to launch the application in response to a request to launch the application by using a parent root process (e.g., see root process 608) and multiple processes (e.g., see forked processes 610a, 610b, and 610c).

[0098] Regarding method 700, at least some or each of the multiple forked processes may be different from the parent root process of the application. The differences may be based on different applications and different parts of applications to be run on the computing device. And at least at some point in executing the application, at least some or each of the multiple forked processes may be the same as the parent root process of the application.

[0099] Specifically, Figure 8 illustrates operations of method 800 performed by Figure 1 , 4 and the mobile device 102 depicted in 6 or by another type of computing device configured similarly to the mobile device 102. Additionally, in some embodiments, method 800 may be performed by an operating system of a computing device generally or an operating system of a mobile device. Method 800 may also be performed by a hypervisor and / or one or more operating systems.

[0100] AsFigure 8 as shown in, method 800 begins with Figure 5 method 500 shown in or Figure 7 method 700 shown in. At step 802, method 800 continues to receive a request to end the application from the user. For example, at step 802, method 800 continues to receive a request to end the application from a user of a computing device (e.g., a user of a mobile device).

[0101] At step 804, method 800 continues to at least partially end the application after receiving the request to end the application. At step 806, method 800 continues to at least partially end the root process of the application after receiving the request to end the application.

[0102] As Figure 8 shown in, at step 808, when step 806 is completed, method 800 continues to at least partially re - execute the root process according to a predetermined condition (after at least partially ending the application and the root process). At step 808, the root process may be at least partially re - executed based on the previous execution pattern of the application. Additionally, at step 808, at least a partial re - execution of the root process may be updated by the previous execution pattern of the application.

[0103] As Figure 8 shown in, at step 810, when step 806 is not completed, method 800 proceeds to continue running the root process of the application after receiving the request to end the application. In other words, method 800 may include receiving a request to end the application from a user of a mobile device at step 802, and then at step 804, the method may include at least partially ending the application after receiving the request to end the application, and then at step 810, the method may include continuing to run the root process of the application after receiving the request to end the application and not stopping the root process between steps 804 and 810. Thus, if the user decides to restart the at least partially ended application or other applications that can use this root process, the root process of the application can be reused again.

[0104] In some embodiments, such as embodiments in which methods 500 and 700 may be implemented, the previous execution pattern of the application stems from the use of the application on a particular computing device (e.g., a particular mobile device) by a particular user and other users, such that the root process is customized for the use of the application on the particular computing device by any user.

[0105] In some other embodiments (e.g., some other embodiments in which methods 500 and 700 may be implemented), the previous execution mode of the application program is derived from the use of the application program by a specific user on a specific computing device (e.g., a specific mobile device), such that the root process is customized for the use of the application program by the specific user on the specific mobile device.

[0106] In some other embodiments (e.g., some other embodiments in which methods 500 and 700 may be implemented), the previous execution mode of the application program is derived from the use of the application program by a specific user on a specific computing device (e.g., a specific mobile device) and at least one other computing device, such that the root process is customized for the use of the application program by the specific user on the computing device and at least one other computing device.

[0107] Regarding method 200, method 300, method 500, method 700, method 800, or any other method, process, or operation described herein, in some embodiments, a non-transitory computer-readable storage medium stores instructions that, when executed by at least one processing device (e.g., Figure 9 the controller 906 shown in) cause the at least one processing device to perform method 200, method 300, method 500, method 700, method 800, or any other method, process, or operation described herein, and / or any combination thereof.

[0108] For example, some embodiments may include a non-transitory computer-readable storage medium tangibly encoded with computer-executable instructions that, when executed by a processor associated with a computing device, perform a method such as Figure 2 method 200 as shown in. Additionally, for example, some embodiments may include a non-transitory computer-readable storage medium tangibly encoded with computer-executable instructions that, when executed by a processor associated with a computing device, perform a method such as Figure 3 method 300 as shown in, Figure 5 method 500 as shown in, Figure 7 method 700 as shown in, and Figure 8 method 800 as shown in, etc.

[0109] Additionally, for example, some embodiments may include a non-transitory computer-readable storage medium tangibly encoded with computer-executable instructions that, when executed by a processor associated with a computing device, can execute a method of monitoring multiple processes of an application in a mobile device. The method may further include scoring objects or components used by the multiple processes during application startup to determine the placement of the objects or components in memory during application startup. And, during application startup, the method may further include loading objects or components scored at a first level into a first portion of memory, and loading objects or components scored at a second level into a second portion of memory. Objects or components scored at the second level may be less important for starting the application than objects or components scored at the first level.

[0110] Additionally, for example, some embodiments may include a method that includes monitoring multiple processes of an application during application startup by an OS in a mobile device. Monitoring of the multiple processes may occur in a background process. The method may further include scoring objects or components used by the multiple processes during application startup to determine the placement of the objects or components in memory during application startup. And, during application startup, the method may include loading objects or components scored at a first level into a first portion of memory, and loading objects or components scored at a second level into a second portion of memory. Objects or components scored at the second level may be less important for starting the application than objects or components scored at the first level.

[0111] Figure 9 Illustrate an example computing device 900 that can implement an initial data distribution for different application processes according to some embodiments of the present disclosure. According to some embodiments of the present disclosure, the computing device 900 may also implement creating a customized root process for an individual application or a group of applications. The device 900 can be or include a mobile device 102 or any other type of computing device (which is or is somewhat similar to a mobile device), or a part thereof, such as a smartphone, a tablet computer, an IoT device, a smart TV, a smart watch, glasses, or other smart household appliances, an in-vehicle infotainment system, a wearable smart device, a game console, a PC, a digital camera, or any combination thereof. As shown, the device 900 may be connected to a communication network 914, which includes at least a wide area network (WAN), a local area network (LAN), an intranet, an extranet, the Internet, and / or any combination thereof.

[0112] Each computing or mobile device described herein (e.g., mobile device 102 or computing device 900) may be or be replaced by a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), cellular phone, network device, server, network router, switch, or bridge, or any machine capable of executing a set of instructions (sequentially or otherwise) that specify actions to be taken by that machine.

[0113] Additionally, although a single machine is illustrated for device 900 shown in Figure 9 and mobile device 102 shown in Figure 1 and 4 and 6, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methods or operations discussed herein. Also, each of the illustrated computing or mobile devices may each at least include a bus and / or motherboard, one or more controllers (e.g., one or more CPUs), main memory that may include temporary data storage, at least one type of network interface, a storage system that may include permanent data storage, and / or any combination thereof. In some multi-device embodiments, one device may complete some parts of the methods described herein and then send the completed results over a network to another device such that the other device may continue with other steps of the methods described herein.

[0114] Figure 9 An example portion of an example computing device 900 in accordance with some embodiments of the present disclosure is also illustrated. Device 900 may be communicatively coupled to network 914, as shown. Device 900 includes at least bus 904, controller 906 (e.g., CPU), memory 908, network interface 910, data storage system 912, and other components 916 (which may be any type of components present in a mobile or computing device, such as GPS components, I / O components, and sensors). Other components 916 may include one or more displays, different types of sensors, audio and / or visual input / output devices, additional dedicated memory, one or more additional controllers (e.g., GPU), or any combination thereof. Bus 904 communicatively couples controller 906, memory 908, network interface 910, data storage system 912, and other components 916. Device 900 includes a computer system that includes at least controller 906, memory 908 (e.g., read only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), static random access memory (SRAM), etc.), and data storage system 912 that communicate with each other via bus 904 (which may include multiple buses).

[0115] In other words, Figure 9 is a block diagram of an example apparatus 900 of a computer system in which embodiments of the present disclosure may be operative. In some embodiments, the computer system may include a set of instructions that, when executed, cause the machine to perform any one or more of the methods discussed herein. In such embodiments, the machine may be connected (e.g., networked via network interface 910) to other machines in a LAN, an intranet, a mobile wireless network such as 4G or 5G, an extranet, and / or the Internet (e.g., network 914). The machine may operate in the capacity of a server or a client machine in a client-server network environment as a peer machine in a peer (or distributed) network environment as described herein or as a server or a client machine in a cloud computing infrastructure or environment.

[0116] Controller 906 represents one or more general-purpose processing devices, such as a microprocessor, a central processing unit, etc. More specifically, the processing device may be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a single instruction multiple data (SIMD), a multiple instruction multiple data (MIMD), or a processor implementing other instruction sets, or a processor implementing a combination of instruction sets. Controller 906 may also be one or more dedicated processing devices, such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), a network processor, etc. Controller 906 is configured to execute instructions for performing the operations and steps discussed herein. Controller 906 may further include a network interface device such as network interface 910 to communicate via one or more communication networks (e.g., network 914).

[0117] Data storage system 912 may include a machine-readable storage medium (also referred to as a computer-readable medium) having stored thereon one or more instruction sets or software embodying any one or more of the methods or functions described herein. The instructions may also reside, completely or at least partially, within memory 908 and / or within controller 906 during execution by the computer system, memory 908 and controller 906 also constituting machine-readable storage media. Memory 908 may be or include the main memory of apparatus 900.

[0118] Although the memory, the controller, and the data storage device portions are shown as separate portions in the example embodiment, each portion should be considered to include a single portion or multiple portions capable of storing instructions and performing their corresponding operations. The term "machine-readable storage medium" should also be considered to include any medium that is capable of storing or encoding a set of instructions for a machine to execute and cause the machine to perform any one or more of the methods of the present disclosure. Thus, the term "machine-readable storage medium" should be considered to include, but not be limited to, solid state memories, optical media, and magnetic media.

[0119] Figure 10 Referring to the mobile device 102 depicted in Figure 1 、 4 and 6, which includes an alternative instance of the root process. As Figure 10 shown, the mobile device 102 includes a controller and a memory 404, as well as four instance scenarios of the alternative of the root process (see the instance scenarios 1, 2, 3, and 4 shown in Figure 10 ). Figure 10 The mobile device 102 shown in Figure 1 、 4 and 6 may also include aspects of the mobile device 102 shown in

[0120] Figure 10 The first instance scenario shown in Figure 6 is scenario 1. In scenario 1, as shown in

[0121] Figure 10 , the application 606a is depicted. The application 606a includes a root process 608, and the root process forks into multiple forked processes (e.g., see the forked processes 610a, 610b, and 610c). Figure 10 The second instance scenario shown in

[0122] Figure 10 is scenario 2. In scenario 2, the application 1002 includes a root process "a", and the application 1004 includes a root process "b". In scenario 2, it is shown that different root processes are used by multiple applications. This is a many-to-many mapping instance, which is a superset of the many-to-one mapping instance. The root process for an application can be used by two or more applications. Additionally, a one-to-many mapping instance can be used in some of the embodiments described herein. For example, multiple different root processes can be used by a single application. As Figure 10Show the forked processes generated by the OS used by application 1006). Also, the OS 1008 can request forked processes from any application to modify and / or generate its own processes (e.g., see forked process 2 forked from the root process "a" of application 1006, which is shown as being used by the OS). Also, other applications besides the OS can also use forked process 2 forked from the root process "a" of application 1006.

[0123] Figure 10 The fourth example case shown in is case 4. In case 4, application 1010 contains the root process "a", and application 1012 contains the root process "b". In case 4, forked processes 1 and 2 are forked from the root process "a" of application 1010, and at least forked process 1 is also forked from the root process "b" of application 1012. Case 4 shows the merging of two forked processes from different applications into one forked process (e.g., see forked process 1). In some examples, the forked processes from different applications can be different forked processes that are merged into a combined and merged forked process. In some other examples, the merged forked process can contain the same processes and / or data. In Figure 10 the case 4 shown, the merging implementation can be done via a merge fork, which can include a special forked process that contains the merging of forked processes. The special forked process can be an OS system call. The special fork with merging can take one or more processes as input (e.g., each process represented by bytecode) and merge the processes into one reference process. It can use a merge mode (e.g., a merge mode described by an XML file). The merge mode can point to sections of bytecode and data, and each section can represent a certain function call or task. The merge mode can also provide instructions for the merging of each section (e.g., the relevant section in the first process is replaced by the section in the second process, or inserted into the first process A, etc.).

[0124] Some parts of the foregoing detailed description have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means by which those skilled in the data processing arts can most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, considered to be a self-consistent sequence of operations that produce a desired result. The operations are those requiring physical manipulation of physical quantities. These quantities are often but not necessarily in the form of electrical or magnetic signals capable of being stored, combined, compared, and otherwise manipulated. Sometimes, it has proven convenient for general reasons to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc.

[0125] However, it should be borne in mind that all these and similar terms are to be associated with appropriate physical quantities and are merely convenient labels applied to these quantities. The present disclosure may refer to actions and processes of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electronic) quantities within the registers and memories of the computer system into other data similarly represented as physical quantities within the memories or registers of the computer system or other such information storage systems.

[0126] The present disclosure also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the intended purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk (including floppy disks, optical disks, CD-ROMs, and magnetic optical disks), read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic or optical cards, or any type of media suitable for storing electronic instructions, each coupled to the computer system bus.

[0127] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized devices to perform the methods. The structure of various of these systems will be presented as will be set forth in the description below. Additionally, the present disclosure has not been described with reference to any particular programming language. It should be appreciated that a variety of programming languages may be used to implement the teachings of the present disclosure as described herein.

[0128] The present disclosure may be provided as a computer program product or software, which may include a machine-readable medium having stored thereon instructions that can be used to program a computer system (or other electronic devices) to perform a process according to the present disclosure. The machine-readable medium includes any mechanism for storing information in a machine (e.g., computer) readable form. In some embodiments, the machine-readable (e.g., computer-readable) medium includes a machine (e.g., computer) readable storage medium such as read-only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory components, etc.

[0129] In the foregoing specification, embodiments of the present disclosure have been described with reference to specific example embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of the embodiments of the present disclosure as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims

1. A method, comprising: Monitoring multiple processes of an application in a mobile device; Scoring an object or component used by the multiple processes to determine placement of the object or component in a memory of the mobile device during startup of the application; And During startup of the application: Loading, at least in part, by a root process of the application, the object or component scored at a first level into a first portion of the memory; And Loading, at least in part, by the root process of the application, the object or component scored at a second level into a second portion of the memory, wherein the object or component scored at the second level is less important to the application than the object or component scored at the first level.

2. The method according to claim 1, wherein the startup of the application includes executing the root process of the application.

3. The method according to claim 2, wherein the root process includes the loading of the object or component scored at the first level.

4. The method according to claim 3, wherein the root process includes the loading of the object or component scored at the second level.

5. The method according to claim 1, wherein the first portion of the memory includes dynamic random access memory (DRAM).

6. The method according to claim 5, wherein the second portion of the memory includes non-volatile random access memory (NVRAM).

7. The method according to claim 6, wherein the NVRAM includes 3D XPoint memory.

8. The method according to claim 1, comprising storing corresponding identifiers and scores of the scored objects or components in a score table.

9. The method according to claim 1, wherein the scoring is at least in part based on machine learning.

10. The method according to claim 9, comprising: Repeating the monitoring of the multiple processes, the scoring of the object or component, and the loading of the object or component; And Training at least in part the scoring of the object or component through each repetition of the monitoring, the scoring, and the loading.

11. The method according to claim 10, wherein the scoring is at least in part based on an artificial neural network (ANN), and wherein the training includes training the ANN.

12. The method according to claim 1, comprising, after startup of the application: Moving at least some of the object or component from the first portion of the memory to the second portion of the memory when usage decreases or is predicted to decrease beyond a first threshold for at least some of the object or component loaded in the first portion; and Moving at least some of the object or component from the second portion of the memory to the first portion of the memory when usage increases or is predicted to increase beyond a second threshold for at least some of the object or component loaded in the second portion.

13. The method according to claim 12, which includes, after the startup of the application: Removing at least some of the objects or components from the second part of the memory when the usage decreases and exceeds a third threshold for at least some of the objects or components in the second part.

14. The method according to claim 1, wherein the startup of the application includes executing the root process of the application to an initial point according to a previous execution pattern of the application.

15. The method according to claim 14, which includes: Receiving a request from a user of the mobile device to start the application; And After receiving the request to start the application, starting the application in the mobile device by using the root process of the application.

16. The method according to claim 15, wherein at least one of the execution, receiving, or starting is performed by an operating system (OS) in the mobile device.

17. The method according to claim 15, which includes: Forking the root process of the application into multiple processes by an operating system (OS) in the mobile device; And After receiving the request to start the application, starting the application in the mobile device by using at least one of the multiple processes according to the request to start the application.

18. The method according to claim 17, wherein at least some of the multiple processes are different from the root process.

19. A non-transitory computer-readable storage medium tangibly encoded with computer-executable instructions, the computer-executable instructions, when executed by a processor associated with a computing device, perform a method, the method including: Monitoring multiple processes of an application in a mobile device; Scoring objects or components used by the multiple processes during the startup of the application to determine the placement of the objects or components in the memory of the mobile device during the startup of the application; And During the startup of the application: Loading the objects or components scored at a first level into a first part of the memory by the root process of the application; And Loading the objects or components scored at a second level into a second part of the memory by the root process of the application, wherein the objects or components scored at the second level are less important for starting the application than the objects or components scored at the first level.

20. A method, which includes: Monitoring, by an operating system (OS) in a mobile device, multiple processes of an application during the startup of the application, wherein the monitoring of the multiple processes is a background process; Scoring objects or components used by the multiple processes during the startup of the application to determine the placement of the objects or components in the memory of the mobile device during the startup of the application; And During the startup of the application: Loading the objects or components scored at a first level into a first part of the memory by the root process of the application; And The root process of the application loads the object or component rated at the second level into the second part of the memory, where the object or component rated at the second level is less important for starting the application than the object or component rated at the first level.

Images