Runtime memory management method and device, operating system, virtual machine, equipment, terminal, medium and program
By establishing module memory links and parsing bytecode when selecting applications, the problem of variable location, addressing, and security isolation between multiple modules or the same module in resource-constrained devices is solved, achieving secure isolation of variable data and efficient memory access.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-29
- Publication Date
- 2026-03-10
AI Technical Summary
In the existing technology, the problems of variable location and addressing between multiple modules or within the same module in resource-constrained devices, as well as the security isolation problems between logical channels of variable data and between modules, have not been effectively solved, resulting in low memory access efficiency.
By calling the entry function when selecting an application, a module memory link is established, the bytecode is parsed to obtain the module information and memory type of the target module, and the starting address of the actual memory space is determined, thereby achieving safe isolation of variable data and efficient memory access.
It ensures the secure isolation of variable data between logical channels and modules, while improving memory access efficiency and solving the variable location and addressing problem.
Smart Images

Figure CN121636129A_ABST
Abstract
Description
Technical Field
[0001] The embodiments of the present invention relate to the field of memory management technology, and in particular to a runtime memory management method, apparatus, operating system, virtual machine, device, terminal, medium and program. Background Technology
[0002] WebAssembly (WASM) is a method for running non-JavaScript (JS, a lightweight, interpreted or just-in-time compiled programming language with function-first approach) script code in a browser. Non-JavaScript code includes languages such as C, C++, or Rust (Rust Programming Language, a memory-safe programming language focused on performance and concurrency). After the non-JavaScript code is loaded into the client browser, it can run at near-native speeds. Module program data is obtained by compiling the program code of a program module using binary intermediate representation (WASM) technology and then converting it using a conversion tool. This module program data can be loaded into resource-constrained devices that support the WaSM virtual machine platform, such as smart card security chips. Resource-constrained devices have limited RAM (Random Access Memory) resources. After the program code is converted by the conversion tool, because the starting positions of global variables in the program data of different modules are the same, and the pre-set compilation allocation starting addresses in the conversion tool are also the same, the starting addresses of global variables in each module are identical after conversion. Therefore, it is necessary to solve the problem of variable location and addressing between multiple modules or within the same module, as well as the problem of secure isolation between logical channels of variable data and between modules. Summary of the Invention
[0003] This invention provides a runtime memory management method, apparatus, operating system, virtual machine, device, terminal, medium, and program that can ensure the secure isolation of variable data between logical channels and modules, while improving memory access efficiency.
[0004] According to one aspect of the present invention, a runtime memory management method is provided, comprising:
[0005] When selecting an application, the entry function of the currently selected application is called to establish module memory links for all modules imported by the currently selected application.
[0006] When the currently selected application code is executed, during the bytecode processing process of the virtual machine executing the target memory instruction to access the memory address, the memory address obtained from the initial bytecode parsing is parsed to obtain the module information and memory type of the target module where the memory is accessed;
[0007] Based on the module information and memory type of the target module, as well as the memory links of the module, determine the starting address of the actual memory space of the target module;
[0008] Address space access is performed based on the starting address of the actual memory space of the target module.
[0009] According to another aspect of the present invention, a runtime memory management apparatus is provided, comprising:
[0010] The module memory link establishment module is used to call the entry function of the currently selected application when selecting an application, and establish module memory links for all modules imported by the currently selected application.
[0011] The first memory address parsing module is used to parse the memory address obtained from the initial bytecode parsing during the bytecode processing process of the target memory instruction accessing the memory address when the currently selected application code is executed in the virtual machine, so as to obtain the module information and memory type of the target module where the memory is accessed.
[0012] The starting address determination module is used to determine the starting address of the actual memory space of the target module based on the module information, memory type, and memory links of the target module.
[0013] The address space access module is used to perform address space access based on the starting address of the actual memory space of the target module.
[0014] According to another aspect of the present invention, an operating system is provided, wherein a runtime environment is executed in the operating system, and the operating system executes the runtime memory management method described in any embodiment of the present invention through the runtime environment.
[0015] According to another aspect of the present invention, a virtual machine is provided, which runs on an operating system, and the operating system executes a runtime environment, through which the operating system executes the runtime memory management method described in any embodiment of the present invention.
[0016] According to another aspect of the present invention, an electronic device is provided, wherein the electronic device is equipped with the operating system described above, the electronic device comprising:
[0017] At least one processor; and
[0018] A memory communicatively connected to the at least one processor; wherein,
[0019] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the runtime memory management method according to any embodiment of the present invention.
[0020] According to another aspect of the present invention, a terminal is provided, comprising the electronic device described above.
[0021] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the runtime memory management method according to any embodiment of the present invention.
[0022] According to another aspect of the present invention, a computer program product is also provided, comprising a computer program that, when executed by a processor, implements the runtime memory management method described in any embodiment of the present invention.
[0023] This invention addresses the problem of variable location and addressing between multiple modules or within the same module, as well as the security isolation of variable data between logical channels and modules, by calling the entry function of the currently selected application when the application is selected. This ensures secure isolation of variable data between logical channels and modules while improving memory access efficiency. During the execution of the currently selected application code, the virtual machine executes target memory instructions to access memory addresses. During the bytecode processing, the memory addresses obtained from the initial bytecode parsing are analyzed to obtain the module information and memory type of the target module. Based on the module information, memory type, and module memory link information, the starting address of the target module's actual memory space is determined. Address space access is then performed based on this starting address. This solution addresses the existing problems of variable location and addressing between multiple modules or within the same module, as well as the security isolation of variable data between logical channels and modules. It ensures secure isolation of variable data between logical channels and modules while improving memory access efficiency.
[0024] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description
[0025] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0026] Figure 1 This is a flowchart of a runtime memory management method provided in an embodiment of the present invention;
[0027] Figure 2 This is a flowchart of another runtime memory management method provided in an embodiment of the present invention;
[0028] Figure 3 This is a flowchart of another runtime memory management method provided in an embodiment of the present invention;
[0029] Figure 4 This is a schematic diagram of a runtime memory management device provided in an embodiment of the present invention;
[0030] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention;
[0031] Figure 6 This is a structural diagram of a terminal provided according to an embodiment of the present invention. Detailed Implementation
[0032] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.
[0033] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0034] Figure 1This is a flowchart of a runtime memory management method provided in an embodiment of the present invention. This embodiment is applicable to situations where module memory links are established to locate variables of the addressing module when selecting an application. This method can be executed by a runtime memory management device, which can be implemented in software and / or hardware, and is generally integrated into an electronic device, which can be a terminal device. The present invention does not limit the specific type of electronic device. Correspondingly, as... Figure 1 As shown, the method includes the following operations:
[0035] S110. When selecting an application, call the entry function of the currently selected application to establish module memory links for all modules imported by the currently selected application.
[0036] The currently selected application is the application that is currently chosen. The entry point function is the point at which the virtual machine starts; the application's entry point function can be defined within a module. A module can include an executable code container for the application within a binary file, containing the application's instructions, data, and metadata, which can be directly executed by the operating system. Module memory linking refers to the processes of memory space allocation, memory address location, and memory access control for global or local data memory accessed by the program in the binary executable file during runtime.
[0037] In resource-constrained devices, after an application is explicitly selected via the SELECT command, the application is considered active on the current logical channel. Applications can be selected implicitly or explicitly. When the RTE (Runtime Environment) receives a SELECT command, if the command content matches the application's AID (Application Identifier), the application is explicitly selected, and the RTE should activate this application as the selected application. When an application is selected when the MANAGE CHANNEL command opens a logical channel, it is implicitly selected. After successful application selection, that application should become the currently selected application. An application can be selected on multiple logical channels, not just one. That is, the same application can be selected by multiple different SELECT commands on multiple logical channels and can be in different states simultaneously.
[0038] Module memory linking is one of the processing steps in the module loading process. Module loading refers to the process by which the application installer loads the binary loadable file into the AOS (Multi-Application Smartcard Operation System), completing the conversion of the in-card link into a binary executable file. This includes module function linking and module memory linking. Module function linking can be executed when the binary loadable file is loaded into the AOS. Module memory linking can also be executed when the binary loadable file is loaded into the AOS. When loading the data segment of the binary loadable file, memory is allocated to store the data segment data and the memory address of the data segment is recorded, completing the memory linking in the loading stage.
[0039] In existing technologies, when addressing the issues of variable location and addressing between multiple modules or within the same module, and the security isolation between logical channels of variable data and between modules, a common technique is to dynamically allocate memory space for the variable data of the modules called by the application in real time during application runtime. This memory management method requires triggering during module calls, thus reducing the efficiency of memory access during application runtime.
[0040] In this embodiment of the invention, when the RTE (Resource-Driven Expansion) selects an application within a resource-constrained device, after calling the entry function of the currently selected application, module memory links for all modules imported by the currently selected application can be established. Therefore, this embodiment of the invention can allocate memory space for the variable data of all modules imported by the selected application at the time of application selection, which is a method of pre-allocating memory for module variable data. Thus, allocating memory space for the variable data of all modules imported by the selected application at the time of application selection avoids the need for real-time dynamic allocation of memory space for the variable data of called modules during application runtime. This not only solves the variable location and addressing problem between multiple modules or within the same module, and the security isolation problem between logical channels and modules of variable data, but also improves runtime memory access efficiency.
[0041] It should be noted that when there are multiple logical channels, module memory links can be established on each open logical channel for all modules imported by the selected application on that channel.
[0042] S120. When the selected application code is executed, during the bytecode processing of the target memory instruction executed by the virtual machine to access the memory address, the memory address obtained from the initial bytecode parsing is parsed to obtain the module information and memory type of the target module where the memory is accessed.
[0043] The target memory instruction can be any instruction type that involves memory access, such as a memory data loading instruction or a memory data storage instruction. This embodiment of the invention does not limit the specific instruction type of the target memory instruction. For example, memory data loading instructions may include, but are not limited to, i32.load, i32.load8_s, i32.load8_u, i32.load16_s, and i32.load16_u. Memory data storage instructions may include, but are not limited to, i32.store, i32.store8, i32.store16, memory.copy, and memory.fill. The target module can be the module that the currently selected application will access during code execution via the target memory instruction. Module information can be information that reflects the module type, such as a module identifier. Memory types can include global data space and indirect accessable variable stack. The global data space can include two types: the module global variable memory area and the module read-only data heap. The module global data memory area stores global data, which refers to data defined in the AOS application that is visible to the entire module. Its scope is limited to the specific module, and it is also known as a global variable. This type of data is typically used to share information within a module, but is not visible or accessible to other modules. The heap area stores module read-only data (also called module read-only variables). Module read-only data can be global data that is visible to the entire module but can only be read and not modified. It is typically used to store constants, configuration information, or other values that do not change during application runtime. The indirect access variable stack stores information about method calls in the AOS application, including combined data types such as local arrays and structures.
[0044] Once the selected application is chosen, the virtual machine can execute target memory instructions during the execution of the application code. This execution involves accessing memory addresses. Specifically, each module function, after compilation, generates a series of bytecode. During bytecode processing, the virtual machine can parse the memory addresses obtained from the initial bytecode parsing to obtain the module information and memory type of the target module containing the accessed memory, thus linking the target module to the actual memory address.
[0045] S130. Determine the starting address of the actual memory space of the target module based on the module information, memory type, and memory links of the target module.
[0046] S140. Access the address space according to the starting address of the actual memory space of the target module.
[0047] In this context, actual memory space refers to the physical memory space on the device that is actually available for storing or running data.
[0048] Correspondingly, after determining the module information and memory type of the target module, the starting address of the actual memory space of the target module can be further determined by combining the established module memory links. Thus, address space access can be performed based on the starting address of the actual memory space of the target module, thereby solving the problem of locating and addressing the variable data of the target module.
[0049] In this embodiment of the invention, memory space can be arranged according to actual memory usage for different modules, and data segments and global segments of binary executable files can be defined. The binary executable file, generated by the application installer, is a file that can be directly processed and executed by the executor, including executable modules. During the application module conversion process, the binary intermediate representation of the application module and one or more library module link files can be used as input, and the application converter converts and outputs the binary loadable file and link file of the application module. The binary intermediate representation is a file generated by the application compiler from the source code, following a unified technical standard to ensure that different language compilers generate uniform intermediate files. Based on the binary link files, the application converter is provided with external function linking information of the binary intermediate representation being converted, thereby generating the final binary loadable file. The binary loadable file is loaded into AOS, becoming the binary executable file. The data segment of the binary intermediate file can store memory initialization data, mainly including two parts: memory offset (where to start memory initialization) and initial data. Memory offset refers to the offset of a specific address within a segment relative to the segment's starting address (segment address) after memory segmentation. The memory offset is also specified by an expression. The global segment of a binary intermediate file can include all global variable information defined within the module. When the binary loadable file is loaded into AOS, module memory linking is performed. When loading the binary loadable file's data segment, memory is allocated to store the data segment data and its memory address is recorded, completing the memory linking during the loading phase. Therefore, by arranging memory space according to actual memory usage and defining data and global segments to establish module memory linking, the variable location and addressing problems between multiple modules or within the same module, as well as the security isolation problems between logical channels of variable data and between modules, can be solved.
[0050] In a specific example, when the virtual machine executes the application code of the currently selected application, it can execute memory data loading instructions such as `i32.load`, `i32.load8_s`, `i32.load8_u`, `i32.load16_s`, and `i32.load16_u`, or memory data storage instructions such as `i32.store`, `i32.store8`, `i32.store16`, `memory.copy`, and `memory.fill`. Executing these target memory instructions will access memory addresses. Since each module function generates a series of bytecode after compilation, during the processing of the bytecode corresponding to the memory address accessed by the target memory instruction, the memory address inherent in the bytecode can be parsed to obtain the module and memory type of the target module where the accessed memory resides, and then linked to the actual memory address. The target memory instruction will have memory offset information, also known as an offset, which refers to the distance between the actual address of a storage unit and the segment address of its segment. The memory offset information included in the target memory instruction may be the operand `memarg.offset` or a value popped from the operand stack. Simultaneously, the target memory instruction typically requires a memory base address, `addr`. This base address is pushed onto the operand stack by other numerical instructions. For example, `i32.load` pushes a base address of 0 onto the operand stack using `i32.const_0`. The base address information pushed onto the operand stack by `const.addr_u8` includes module information and the base address value. Module information includes, for example, the module identifier, and the base address value can be formatted as `((module identifier << 16) | module base address)`. Adding the base address `addr` to a memory offset, such as `memory.offset`, yields the memory address. Correspondingly, the memory offset between the base address and the bytecode represents the final memory type determined by the parsed bytecode.
[0051] However, some bytecode does not require configuring a base address and directly uses the value popped from the operand stack as the memory offset, such as the `memory.copy` and `memory.fill` instructions. This is because before executing this part of the bytecode, the bytecode related to the memory variable base address operation has already been executed, for example, `i32.const_0` -> `local.get_2` -> `i32.add`, and finally the calculated memory offset is pushed onto the operand stack to be passed to instructions such as `memory.copy` and `memory.fill`.
[0052] Accordingly, after determining the module information and memory type of the target module, the module memory link information can be found based on the module information and memory type of the target module to determine the starting address of the actual memory space of the target module, and then address space access can be performed based on the starting address of the actual memory space of the target module.
[0053] In an optional embodiment of the present invention, the runtime memory management method may further include: when the currently selected application code is executed, during the bytecode processing of the API (Application Programming Interface) call in the virtual machine, parsing the memory address passed during function parameter passing to obtain the module information and memory type of the memory being accessed; determining the starting address of the actual memory space of the target module based on the module information and memory type of the target module and the memory link of the module; and performing address space access based on the starting address of the actual memory space of the target module.
[0054] Understandably, during the execution of application code by the virtual machine, it may also execute API calls. For example, when the virtual machine executes the bytecode of function calls such as `call_u16`, `call_outer_u8`, `call_inner_u8`, and `call_indirect`, the function parameters are pointers, arrays, and structures. The actual parameter passed is a memory offset, which has already been pushed onto the operand stack through bytecode operations during the function call. Correspondingly, during the bytecode processing of the API call, the memory address passed during function parameter passing can be parsed to obtain the module information and memory type of the target module where the memory is accessed. Then, based on the module information, memory type, and memory links of the target module, the starting address of the actual memory space of the target module can be determined, and address space access can be performed based on the starting address of the actual memory space of the target module.
[0055] This invention addresses the problem of variable location and addressing between multiple modules or within the same module, as well as the security isolation of variable data between logical channels and modules, by calling the entry function of the currently selected application when the application is selected. This ensures secure isolation of variable data between logical channels and modules while improving memory access efficiency. During the execution of the currently selected application code, the virtual machine executes target memory instructions to access memory addresses. During the bytecode processing, the memory addresses obtained from the initial bytecode parsing are analyzed to obtain the module information and memory type of the target module. Based on the module information, memory type, and module memory link information, the starting address of the target module's actual memory space is determined. Address space access is then performed based on this starting address. This solution addresses the existing problems of variable location and addressing between multiple modules or within the same module, as well as the security isolation of variable data between logical channels and modules. It ensures secure isolation of variable data between logical channels and modules while improving memory access efficiency.
[0056] Figure 2This is a flowchart of another runtime memory management method provided by an embodiment of the present invention. This embodiment is based on the above embodiment and is further specified. In this embodiment, various specific optional implementation methods for establishing module memory links for all modules imported by the currently selected application are given. Accordingly, as Figure 2 As shown, the method in this embodiment may include:
[0057] S210. When selecting an application, call the entry function of the currently selected application, find all other modules imported by the module code of the currently selected application, and record the information of all imported modules.
[0058] In this embodiment of the invention, module memory links for all modules imported by the currently selected application can be established in real time when the application is selected. Specifically, after calling the entry function of the currently selected application when selecting an application, all other modules imported by the module code of the currently selected application can be found, and information about all imported modules can be recorded. Optionally, the recorded module information may include, but is not limited to, the identifier of the imported module and the size of the module global data (rwdata) space of the imported module.
[0059] S220. When selecting an application, memory space is allocated sequentially for the recorded imported modules and the module where the selected application is located, and the allocated memory space information is recorded.
[0060] Simultaneously, during application selection, memory space can be allocated sequentially for the recorded imported modules and the module containing the currently selected application, and information related to the allocated memory space can be recorded. For example, the information regarding the allocated memory space may include, but is not limited to: the starting address of each memory space and / or the starting offset of the memory space for each module. The starting offset of the memory space can be understood as an offset based on the predefined starting address of the memory space.
[0061] S230. Establish the association between the module information and the memory space information allocated to the module to obtain the memory link information of the module.
[0062] Accordingly, after recording the memory space information allocated to the currently selected application, an association can be established between the target module's module information and the module's allocated memory space information, thereby obtaining the module's memory link information. For example, a mapping between the module's identifier and the starting address or offset address of the module's memory space can be established to obtain the module's memory link information. For instance, an association can be established between the module identifier and the module's memory space (such as the starting address or offset address of the module's memory space). This embodiment of the invention does not limit the method of association between module information and the module's allocated memory space information.
[0063] The above technical solution establishes a dynamic association between module information and the memory space allocated to the module when the application entry function is called, which serves as the module memory link information. When the application entry function is called, the dynamically established module memory link information may be updated, which can save RAM space and thus save memory resources.
[0064] Therefore, when selecting an application, if the entry function of the application on the current logical channel is called, after searching for all other modules imported by the module code of the currently selected application and recording all imported module information, it can first check whether the currently selected application or its module has already established module memory link information. If it has, there is no need to update the module memory link information, and the command can be dispatched directly; otherwise, memory space should be allocated based on the module information of the currently selected application, the association between the module information and the memory space information allocated by the module should be established, the module memory link information should be obtained, and the application or module associated with the current module memory link information should be recorded.
[0065] In an optional embodiment of the present invention, establishing module memory links for all modules imported by the currently selected application may further include: accessing module information to locate the module memory links; wherein, the module information may include module management information or NVM (Non-Volatile Memory) space.
[0066] Module information can include two types: module management information or NVM space. Module management information can be used to manage the application's memory allocation information.
[0067] In this embodiment of the invention, module memory links for all modules imported by the currently selected application can also be established by accessing module information to find module memory link information. It is understood that before searching for module memory link information, module memory links for each application need to be established in advance.
[0068] In an optional embodiment of the present invention, before the access module management information searches for the module memory link, the method may further include: determining the target generation method of the memory link of the module to which the application belongs based on the application release method; and generating the module memory link information of the application using the target generation method.
[0069] The application distribution method can be the distribution type of the binary file containing the application module, which can include both pre-installed (masked) and post-download distribution methods. The target generation method can be the way in which different types of applications generate memory link information for their modules.
[0070] In this embodiment of the invention, different application deployment methods result in different methods for generating module memory link information. Therefore, before configuring the generation of application module memory link information, it is necessary to analyze and determine the application deployment method, thereby determining the target generation method for matching application module memory links based on the application deployment method, and generating the application module memory link information using the matching target generation method for each type of application.
[0071] In an optional embodiment of the present invention, the application publishing method may include downloading the application after downloading; the step of generating the module memory link information of the application using the target generation method may include: during the download process of the binary executable file of the application after downloading, generating memory space logical allocation information for each module based on the information of all modules imported by the import segment of the binary executable file; and storing the memory space allocation information of each module in the module information of the currently downloaded module.
[0072] The subsequently downloaded application can be an application that needs to be installed and executed through the AOS application installer. The AOS application installer loads the binary loadable file of the subsequently downloaded application into the operating system as a binary executable file, installs the modules contained in the binary executable file as an application instance, registers and initializes it, making it a selectable and executable application instance. The binary executable file is generated by the AOS application installer. It is a file that can be directly processed and executed by the executor, including executable modules. The binary loadable file, once loaded into AOS, becomes a binary executable file. The binary loadable file contains information about the executable module, including the application's imports, functions, globals, exports, elements, and code information. Correspondingly, after the binary loadable file is loaded into AOS as a binary executable file, the import sections included in the binary executable file can be decoded into import function information representing module components. The currently downloaded module can be a module of the binary executable file of the currently downloaded subsequently downloaded application.
[0073] For applications downloaded later, during the download process of the binary executable file, initial linking can be performed based on the imported `mudule_aid` (i.e., module AID) in the imported section of the binary executable file. The linking process involves parsing and locating the module identified by `mudule_aid` based on the imported module's `mudule_aid` information, caching all parsed and located module information, which may include the module's internal representation, the content of module management information (e.g., the module registry), or the storage location of module management information. The module's internal representation can be its identifier on the device, i.e., the module identifier. Further, information on all located modules can be read, and information on its global segment can be obtained from the binary executable file of the application downloaded later. The size of the `rwdata` (module global data) variable can be calculated, and memory space can be allocated to the `rwdata` variable to generate memory space allocation information for each module. Finally, the memory space allocation information for each module can be stored in the module management information or NVM space of the currently downloaded module. It should be noted that if the memory space allocation information of each module needs to be stored in the NVM space, an association between the corresponding NVM space and the currently downloaded module needs to be established so that the module memory link information can be obtained by querying the corresponding NVM space.
[0074] In an optional embodiment of the present invention, the application publishing method may include a pre-built application; the method of generating the module memory link information of the application using the target generation method may include: generating memory space logical allocation information for each module imported by the application module import segment during the generation of the mask file; and outputting the memory space allocation information of each module as the module information generation data to the mask file for storage.
[0075] Pre-installed applications are those pre-loaded and configured within the system, eliminating the need for loading via the AOS application installer. The module memory links of these pre-installed applications can be stored in mask data files. The corresponding binary loadable file for the pre-installed application resides outside the device; a masking tool generates the corresponding mask data file. This mask data can be compiled along with other operating system code to form a production file, which is then pre-installed within the operating system. On the device, only the instance (application) of the pre-installed application module needs to be installed.
[0076] Correspondingly, for pre-built applications, during the process of generating mask files using the Mask tool, information on the memory space allocation of all modules imported by the application module (including the application module itself) can be generated to generate the module memory links of the pre-built application. Then, the memory space allocation information of each module can be used as the generated data of the module information and output to the mask file for storage.
[0077] In an optional embodiment of the present invention, generating memory space allocation information for each module may include: obtaining global segment information of the module and calculating the space size of global segment module global data; allocating memory space for the module global data and recording the first memory space allocation information; allocating memory space for all imported module local variables and recording the second memory space allocation information.
[0078] The first memory space allocation information can be calculated for global variables of non-imported modules. The second memory space allocation information can be calculated for global variables of imported modules.
[0079] Specifically, for both downloaded and pre-installed applications, when generating memory space allocation information for each module, the size of the `rwdata` variable (module global data) can be calculated for each module. Then, the first memory space allocation information can be allocated to the `rwdata` variable, and this allocation information can be recorded. For example, the memory address, size, or offset allocated to the module's `rwdata` variable (module global data) can be recorded. Simultaneously, a second memory space allocation information can be allocated to the `rwdata` variables of all imported modules, and this allocation information can be recorded. For example, the memory offset allocated to the imported module's `rwdata` variable can be recorded. The memory space allocated to the module's `rwdata` variable can specifically be RAM space.
[0080] The method described above, which establishes module memory links for all modules imported by the currently selected application by accessing module information to find module memory links, eliminates the need to dynamically establish the association between module information and the memory space allocated to the module as module memory link information when the application's entry function is called. Instead, it only needs to look up the pre-configured module memory link information based on module management information or NVM space, and can then directly read and use it. To further accelerate access speed, the pre-configured module memory link information can also be cached in a RAM data structure, recording the application or module associated with each module memory link. When the entry function of the application on the currently processing command's logical channel is about to be called, the module memory link information of that application or its module is read, and the command is directly dispatched, further improving memory access efficiency.
[0081] S240. When the currently selected application code is executed, during the bytecode processing process of the virtual machine executing the target memory instruction to access the memory address, the memory address obtained from the preliminary bytecode parsing is parsed to obtain the module information and memory type of the target module where the memory is accessed. Alternatively, during the bytecode processing process of the virtual machine executing the API call, the memory address passed during the function parameter passing process is parsed to obtain the module information and memory type of the target module where the memory is accessed.
[0082] S250. Determine the starting address of the actual memory space of the target module based on the module information, memory type, and memory links of the target module.
[0083] S260. Access the address space according to the starting address of the actual memory space of the target module.
[0084] The above technical solution enriches the ways to establish module memory links for all modules imported by the currently selected application by adopting multiple optional methods. This not only ensures the secure isolation of variable data between logical channels and modules, but also further improves memory access efficiency.
[0085] Figure 3 This is a flowchart of another runtime memory management method provided by an embodiment of the present invention. This embodiment is based on the above embodiment and is further specified. In this embodiment, specific optional implementation methods for determining the starting address of the actual memory space of the target module for address space access are given. Correspondingly, as Figure 3 As shown, the method in this embodiment may include:
[0086] S310. When selecting an application, call the entry function of the currently selected application to establish module memory links for all modules imported by the currently selected application.
[0087] S320. When the currently selected application code is executed, during the bytecode processing process of the virtual machine executing the target memory instruction to access the memory address, the memory address obtained from the initial bytecode parsing is parsed to obtain the module information and memory type of the target module where the memory is accessed. Alternatively, during the bytecode processing process of the virtual machine executing the API call, the memory address passed during the function parameter passing process is parsed to obtain the module information and memory type of the target module where the memory is accessed.
[0088] S330. Determine the access space type based on the module information and memory address of the target module.
[0089] In this embodiment of the invention, the access space type may include two types: memory space and indirect access variable stack.
[0090] In an optional embodiment of the present invention, before determining the access space type based on the module information and memory address of the target module, the method may further include: determining the target module as the current module if the module information of the target module is determined to be first module information; or, determining the target module as a designated module if the module information of the target module is determined to be second module information.
[0091] The first module information can be information identifying the current module, such as 0 or other types of identifiers. The current module can be the module of the currently executing function. The second module information can be information identifying a specified module, such as a non-zero identifier or other types of identifiers. The specified module can be a module specified by the current module, i.e., a module imported by the current module.
[0092] When the bytecode of certain target memory instructions is executed, such as memory data loading instructions like i32.load, i32.load8_s, i32.load8_u, i32.load16_s, and i32.load16_u, or memory data storage instructions like i32.store, i32.store8, and i32.store16, the memory address value is parsed. The virtual machine can determine the memory module to access based on the parsed target module's module information. If the target module's module information is determined to be the first module information (e.g., 0), it indicates that the current module is being accessed; if the target module's module information is determined to be the second module information (e.g., non-zero), it indicates that the specified module is being accessed.
[0093] S340. Determine if the access space type is memory space. If yes, execute S350; otherwise, execute S360.
[0094] In this embodiment of the invention, the way to determine the starting address of the actual memory space of the target module is also different depending on the access space type of the target module.
[0095] In an optional embodiment of the present invention, determining that the access space type is memory space may include: if the memory address is less than the size of the read-only variable area in the module information of the target module, then the memory address is determined to point to the heap area of the module's read-only data; if the memory address is greater than or equal to the size of the read-only variable area in the module information of the target module, then the memory address is determined to point to the module's global data memory area.
[0096] In this embodiment of the invention, the RAM memory space can be divided into module global data memory and indirect access variable stack. The virtual machine needs to determine the variable offset pointed to by the accessed address based on the module information and memory address. If the access address points to module read-only data, the data should be searched in the module read-only data area; if the access address points to module global data, the data should be searched in the module global data memory area in conjunction with the logical channel information.
[0097] Generally, if the memory address of the target module is smaller than the size of the read-only variable area in the module information of the target module, it can be determined that the memory address of the target module points to the heap area of the module's read-only data; if the memory address of the target module is greater than or equal to the size of the read-only variable area in the module information of the target module, it can be determined that the memory address of the target module points to the module's global data memory area.
[0098] In a specific example, suppose the memory offset of the module variables in the module information starts with a fixed value, such as 0x10, and then all RO (Read-Only) type variables / data are arranged sequentially, followed by RW (Read-Write) type variables / data in the global data memory area. The global_section structure in the global segment of the corresponding binary executable file of the module includes two structure items: rodadata_base (representing the starting address of the module's read-only data in memory space) and rwdata_base (representing the starting address of the module's global data in memory space), recording the logical starting address of each type of module data in memory space. The virtual machine resolves the memory address of the target module. If the resolved memory address is smaller than the size of the read-only variable (also called read-only data) area in the target module's module information, that is, if the resolved memory address falls within the range [rodata_base, rwdata_base), then the resolved memory address points to the heap area of the module's read-only data, indicating that the accessed data type is a read-only variable. Correspondingly, if the parsed memory address is greater than or equal to the size of the read-only variable area in the module information of the target module, that is, if the parsed memory address belongs to the range of [rwdata_base, data_end), then it is determined that the parsed memory address points to the module's global data memory area, indicating that the accessed data type is a global variable (also known as global data), which is stored in the global data memory area.
[0099] In an optional embodiment of the present invention, determining that the access space type is an indirect access variable stack may include: if the memory address is greater than or equal to the size of the global variable region in the module information of the target module, then determining that the memory address points to the indirect access variable stack.
[0100] Continuing with the example above, the virtual machine resolves the offset of the target module's memory address. If the resolved memory address is greater than or equal to the size of the global variable region in the target module's module information (i.e., the resolved memory address is greater than `rwdata_base`), then the memory address is determined to point to the indirect access variable stack, and the accessed data type may be the indirect access variable stack. In this embodiment of the invention, the memory space of local structure type data is the indirect access variable stack.
[0101] S350. Locate the memory link of the module, determine the memory space type of the target module, use the starting address of the memory space of the target module as the starting address of the actual memory space, and perform address space access based on the starting address of the actual memory space of the target module.
[0102] In this embodiment of the invention, if the access space type of the target module is determined to be memory space, when accessing the address space based on the starting address of the actual memory space of the target module, the module memory link can be searched to determine the memory space type of the target module, and then the starting address of the memory space of the target module can be used as the starting address of the actual memory space.
[0103] In an optional embodiment of the present invention, if the target module is the current module, then the step of accessing the address space based on the starting address of the actual memory space of the target module may include: caching the starting address of the actual memory space of the current module; offsetting the current memory space from the starting address of the actual memory space of the current module according to the module information, memory type, and memory links of the target module to obtain the actual memory address of the accessed data; and performing address space access based on the actual memory address of the accessed data.
[0104] The actual memory space can be the physical memory space. The current memory space can be the starting address of the physical space of the module where the accessed data resides, typically the module where the currently executing bytecode resides. The actual memory address is also the starting address of the actual physical space.
[0105] If the target module is identified as the current module, to speed up address space access based on the starting address of the target module's actual memory space, the starting address of the current module's actual memory space can be cached, or a pointer to the current module's actual memory space can also be cached. Further, based on the target module's module information, memory type, and memory links, the memory space information allocated to the current module is queried to obtain the starting address of the current module's actual memory space. Then, the current memory space is offset from the starting address of the current module's actual memory space to obtain the actual memory address of the data to be accessed. Address space access can then be performed based on the actual memory address of the accessed data.
[0106] In an optional embodiment of the present invention, if the target module is a designated module, then the step of accessing the address space based on the starting address of the actual memory space of the target module may include: offsetting the current memory space from the starting address of the actual memory space of the designated module according to the module information, memory type and memory link of the target module to obtain the actual memory address of the accessed data; and performing address space access based on the actual memory address of the accessed data.
[0107] Correspondingly, if the target module is determined to be a specified module and the access space type is determined to be memory space, the module memory link can be found based on the module information and memory type of the target module to determine the starting address of the actual memory space of the specified module. Then, the current memory space is offset from the starting address of the actual memory space of the specified module to obtain the actual memory address of the accessed data. Address space access can then be performed based on the actual memory address of the accessed data.
[0108] In a specific example, continuing with the previous example, if it is determined that the memory address of the target module (which could be the current module or a specified module) points to the heap area of the module's read-only data, the virtual machine obtains the starting address of the memory space for the target module's read-only data. Generally, the NVM module management information records the starting address of this read-only variable in NVM. After obtaining the starting address of the target module's read-only data memory space, `rodata_base`, the starting address of the target module's actual memory space can be offset from the current memory space. That is, by adding the offset of the target module's current memory address relative to `rodata_base` to the current memory space, the actual memory address for accessing data in the target module can be located, and `rodata` access can be performed. If it is determined that the memory address points to the module's global data memory area, the virtual machine obtains the starting address of the target module's global data memory space, offsets the current memory space from the starting address of the target module's actual memory space, that is, by adding the offset of the target module's current memory address relative to `rwdata_base` to the current memory space, the actual memory address for accessing data in the target module can be located, and `rwdata` memory access can be performed.
[0109] S360. Determine that the access space type is an indirect access variable stack, obtain the actual memory address of the current indirect access variable stack, and perform address space access based on the actual memory address of the current indirect access variable stack.
[0110] In this embodiment of the invention, if the access space type of the target module is determined to be an indirect access variable stack, then when accessing the address space based on the starting address of the actual memory space of the target module, the actual memory address of the current indirect access variable stack can be obtained, and thus the address space can be accessed based on the actual memory address of the current indirect access variable stack.
[0111] In an optional embodiment of the present invention, the step of accessing the address space based on the actual memory address of the current indirect access variable stack may include: obtaining the actual physical memory space of the current indirect access variable stack; offsetting the memory address relative to a set maximum space limit value of the indirect access variable stack to a lower address based on the highest address value of the actual physical memory space, thereby locating the actual memory address of the current indirect access variable stack; or, offsetting the memory address relative to a set base address of the indirect access variable stack based on the starting address of the actual physical memory space, thereby locating the actual memory address of the current indirect access variable stack; and performing address space access based on the actual memory address of the current indirect access variable stack.
[0112] The actual physical memory space can be the memory directly available in the current indirect access variable stack. This memory is the physical space actually used by the computer to store the data and instructions of the executing program during runtime. The value of the highest address of the indirect access variable stack can be set according to requirements, and this embodiment of the invention does not limit the specific value of the maximum space limit of the indirect access variable stack.
[0113] Specifically, the virtual machine can first obtain information about the actual physical memory space of the current indirect access variable stack, such as, but not limited to, its size, end address, or start address. Generally, the indirect access variable stack is multiplexed by multiple modules and logical channels, and is essentially memory space. After obtaining the actual physical memory space of the current indirect access variable stack, the virtual machine can offset the target module's memory address relative to the set maximum space limit of the indirect access variable stack from the highest address (e.g., 64k) of the current indirect access variable stack's actual physical memory space, thereby locating the actual memory address of the current indirect access variable stack. Alternatively, it can also offset the target module's memory address relative to the set base address of the indirect access variable stack from the start address of the current indirect access variable stack's actual physical memory space, thereby locating the actual memory address of the current indirect access variable stack. After locating the actual memory address of the current indirect access variable stack, address space access can be performed based on this address.
[0114] The above technical solution manages RAM memory space by dividing it into a global data space and an indirect access variable stack space. The global data space includes read-only variables and global variables. During application runtime, it provides a method for establishing module memory links for all modules imported by the currently selected application. When the virtual machine executes the bytecode of the target memory instruction to access global variables, it performs physical space mapping according to the offset of the global variable to determine whether the global variable data resides in the indirect access variable stack, the global memory space, or the NVM. This solves the existing problems of variable location and addressing between multiple modules or within the same module, as well as the problem of secure isolation of variable data between logical channels and modules. It ensures secure isolation of variable data between logical channels and modules while improving memory access efficiency.
[0115] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information in this technical solution comply with relevant laws and regulations and do not violate public order and good morals.
[0116] It should be noted that any arrangement or combination of the technical features in the above embodiments also falls within the protection scope of this invention.
[0117] Figure 4 This is a schematic diagram of a runtime memory management device provided in an embodiment of the present invention, such as... Figure 4 As shown, the device includes: a module memory link establishment module 410, a first memory address resolution module 420, a start address determination module 430, and an address space access module 440, wherein:
[0118] The module memory link establishment module 410 is used to call the entry function of the currently selected application when selecting an application, and establish module memory links for all modules imported by the currently selected application.
[0119] The first memory address parsing module 420 is used to parse the memory address obtained from the initial bytecode parsing during the bytecode processing process of the target memory instruction accessing the memory address executed by the virtual machine when the currently selected application code is executed, so as to obtain the module information and memory type of the target module where the memory is accessed.
[0120] The starting address determination module 430 is used to determine the starting address of the actual memory space of the target module based on the module information, memory type, and memory links of the target module.
[0121] Address space access module 440 is used to perform address space access based on the starting address of the actual memory space of the target module.
[0122] This invention addresses the problem of variable location and addressing between multiple modules or within the same module, as well as the security isolation of variable data between logical channels and modules, by calling the entry function of the currently selected application when the application is selected. This ensures secure isolation of variable data between logical channels and modules while improving memory access efficiency. During the execution of the currently selected application code, the virtual machine executes target memory instructions to access memory addresses. During the bytecode processing, the memory addresses obtained from the initial bytecode parsing are analyzed to obtain the module information and memory type of the target module. Based on the module information, memory type, and module memory link information, the starting address of the target module's actual memory space is determined. Address space access is then performed based on this starting address. This solution addresses the existing problems of variable location and addressing between multiple modules or within the same module, as well as the security isolation of variable data between logical channels and modules. It ensures secure isolation of variable data between logical channels and modules while improving memory access efficiency.
[0123] Optionally, the runtime memory management device may further include a second memory address resolution module, used to parse the memory address passed during function parameter passing during the bytecode processing corresponding to the application programming interface (API) call executed by the virtual machine when the currently selected application code is executed, to obtain the module information and memory type of the target module where the memory is accessed; a start address determination module, used to determine the start address of the actual memory space of the target module based on the module information and memory type of the target module and the memory link of the module; and an address space access module, used to perform address space access based on the start address of the actual memory space of the target module.
[0124] Optionally, the starting address determination module is further configured to: determine the access space type based on the module information and memory address of the target module; if the access space type is determined to be memory space, search the module memory link to determine the memory space type of the target module; and use the starting address of the memory space of the target module as the starting address of the actual memory space.
[0125] Optionally, the starting address determination module is further configured to: determine the target module as the current module when the module information of the target module is determined to be first module information; or, determine the target module as a specified module when the module information of the target module is determined to be second module information.
[0126] Optionally, if the target module is the current module, the address space access module is further configured to: cache the starting address of the actual memory space of the current module; offset the current memory space from the starting address of the actual memory space of the current module according to the module information, memory type, and memory link of the target module to obtain the actual memory address of the accessed data; and perform address space access based on the actual memory address of the accessed data.
[0127] Optionally, if the target module is a specified module, the address space access module is further configured to: offset the current memory space from the starting address of the actual memory space of the specified module according to the module information, memory type, and memory link of the target module, to obtain the actual memory address of the accessed data; and perform address space access based on the actual memory address of the accessed data.
[0128] Optionally, the starting address determination module is further configured to: if the memory address is less than the size of the read-only variable area in the module information of the target module, then determine that the memory address points to the heap area of the module's read-only data; if the memory address is greater than or equal to the size of the read-only variable area in the module information of the target module, then determine that the memory address points to the module's global data memory area.
[0129] Optionally, the starting address determination module is further configured to: determine the access space type based on the module information and memory address of the target module; and, if the access space type is determined to be an indirect access variable stack, obtain the actual memory address of the current indirect access variable stack; the address space access module is further configured to: perform address space access based on the actual memory address of the current indirect access variable stack.
[0130] Optionally, the starting address determination module is further configured to: if the memory address is greater than or equal to the size of the global variable region in the module information of the target module, then determine that the memory address points to the indirect access variable stack.
[0131] Optionally, the address space access module is further configured to: obtain the actual physical memory space of the current indirect access variable stack; based on the highest address value of the actual physical memory space, offset the memory address relative to the set maximum space limit value of the indirect access variable stack to a lower address, and locate the actual memory address of the current indirect access variable stack; or, based on the starting address of the actual physical memory space, offset the memory address relative to the set base address of the indirect access variable stack to a lower address, and locate the actual memory address of the current indirect access variable stack; and perform address space access based on the actual memory address of the current indirect access variable stack.
[0132] Optionally, the module memory link establishment module is also used for: when selecting an application, finding all other modules imported by the module code of the currently selected application and recording all imported module information; when selecting an application, allocating memory space sequentially for the recorded imported modules and the module of the currently selected application, and recording the allocated memory space information; establishing the association between the module information and the memory space information allocated by the module to obtain the module memory link information.
[0133] Optionally, the module memory link establishment module is also used to: access module information to find information about the module memory link; wherein, the module information includes module management information or NVM space.
[0134] Optionally, the runtime memory management device further includes a module memory link information generation module, used to: determine the target generation method of the memory links of the module to which the application belongs based on the application release method; and generate the module memory link information of the application using the target generation method.
[0135] Optionally, the application publishing method includes post-download application; the module memory link information generation module is further configured to: during the download process of the binary executable file of the post-download application, generate memory space logical allocation information for each module based on the information of all modules imported by the import segment of the binary executable file; and store the memory space allocation information of each module in the module information of the currently downloaded module.
[0136] Optionally, the application publishing method includes pre-installed applications; the module memory link information generation module is also used to: generate memory space logical allocation information for each module imported by the application module import segment during the generation of the mask file; and output the memory space allocation information of each module as the generated data of module information to the mask file for storage.
[0137] Optionally, the module memory link information generation module is also used to: obtain the global segment information of the module, calculate the space size of the global segment module global data; allocate memory space for the module global data, and record the information of the first memory space allocation; allocate memory space for all imported module global variables, and record the information of the second memory space allocation.
[0138] The above-described runtime memory management device can execute the runtime memory management method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the method. Technical details not described in detail in this embodiment can be found in the runtime memory management method provided in any embodiment of the present invention.
[0139] Since the runtime memory management device described above is an apparatus capable of executing the runtime memory management method in the embodiments of the present invention, those skilled in the art can understand the specific implementation methods and various variations of the runtime memory management device in this embodiment based on the runtime memory management method described in the embodiments of the present invention. Therefore, how the runtime memory management device implements the runtime memory management method in the embodiments of the present invention will not be described in detail here. Any apparatus used by those skilled in the art to implement the runtime memory management method in the embodiments of the present invention falls within the scope of protection of this application.
[0140] This invention also provides an operating system that executes a runtime environment, and the operating system executes the runtime memory management method provided in any embodiment of this invention through the runtime environment.
[0141] This invention also provides a virtual machine that runs on an operating system. The operating system has a runtime environment, and the operating system executes the runtime memory management method provided in any embodiment of this invention through the runtime environment.
[0142] Figure 5 A schematic diagram of the structure of an electronic device 10 that can be used to implement an embodiment of the present invention is shown.
[0143] like Figure 5 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.
[0144] The I / O interface 15 in the electronic device 10 may include eSPI (Enhanced Serial Peripheral Interface) and SPI (Serial Peripheral Interface), etc.
[0145] Processor 11 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, central processing unit (CPU), graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, for example, performing a runtime memory management method as described in various embodiments of the present invention, executed by a runtime environment in an operating system installed in an electronic device, the method comprising:
[0146] When selecting an application, the entry function of the currently selected application is called to establish module memory links for all modules imported by the currently selected application.
[0147] When the currently selected application code is executed, during the bytecode processing process of the virtual machine executing the target memory instruction to access the memory address, the memory address obtained from the initial bytecode parsing is parsed to obtain the module information and memory type of the target module where the memory is accessed;
[0148] Based on the module information and memory type of the target module, as well as the memory links of the module, determine the starting address of the actual memory space of the target module;
[0149] Address space access is performed based on the starting address of the actual memory space of the target module.
[0150] In some embodiments, a runtime memory management method as described in the various embodiments of the present invention can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 16. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the runtime memory management method as described above in the various embodiments of the present invention can be performed. Alternatively, in other embodiments, processor 11 can be configured to execute a runtime memory management method as described in the various embodiments of the present invention by any other suitable means (e.g., by means of firmware).
[0151] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.
[0152] Optionally, electronic devices include resource-constrained devices. Resource-constrained devices include smart cards, SEs (Secure Elements), security chips, or embedded devices.
[0153] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.
[0154] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.
[0155] Figure 6 This is a structural diagram of a terminal provided according to an embodiment of the present invention. Figure 6 The terminal includes the electronic device 10 as described in any embodiment of the present invention.
[0156] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.
[0157] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.
Claims
1. A method of run-time memory management, characterized by, The application comprises: When an application is selected, an entry function of the currently selected application is called to establish a module memory link of all modules imported by the currently selected application; When the currently selected application code is executed, a memory address is accessed by a virtual machine executing a target memory instruction, and in a corresponding bytecode processing process, a memory address obtained through preliminary analysis of bytecode is analyzed to obtain module information and a memory type of a target module accessed by the memory; A starting address of an actual memory space of the target module is determined according to the module information and the memory type of the target module and the module memory link; Address space access is performed according to the starting address of the actual memory space of the target module.
2. The method of claim 1, wherein, The application further comprises: When the currently selected application code is executed, a memory address is accessed by a virtual machine executing an application programming interface (API) call corresponding bytecode processing process, and in a corresponding bytecode processing process, a memory address passed in a function parameter passing process is analyzed to obtain module information and a memory type of a target module accessed by the memory; A starting address of an actual memory space of the target module is determined according to the module information and the memory type of the target module and the module memory link; Address space access is performed according to the starting address of the actual memory space of the target module.
3. The method according to claim 1 or 2, characterized in that, The starting address of the actual memory space of the target module is determined according to the module information and the memory type of the target module and the module memory link, which comprises: A space type is determined according to the module information and the memory address of the target module; In a case where the space type is determined to be a memory space, the module memory link is searched to determine a memory space type of the target module; The starting address of the memory space of the target module is taken as the starting address of the actual memory space.
4. The method of claim 3, wherein, Before the space type is determined according to the module information and the memory address of the target module, the application further comprises: In a case where the module information of the target module is determined to be first module information, the target module is determined to be a current module; or In a case where the module information of the target module is determined to be second module information, the target module is determined to be a specified module.
5. The method of claim 4, wherein, If the target module is the current module, the address space access according to the starting address of the actual memory space of the target module comprises: The starting address of the actual memory space of the current module is cached; According to the module information, the memory type and the module memory link of the target module, an actual memory address of accessed data is obtained by offsetting a current memory space by the starting address of the actual memory space of the current module; Address space access is performed based on the actual memory address of the accessed data.
6. The method of claim 4, wherein, If the target module is the specified module, the address space access according to the starting address of the actual memory space of the target module comprises: According to the module information, the memory type and the module memory link of the target module, an actual memory address of accessed data is obtained by offsetting a current memory space by the starting address of the actual memory space of the specified module; Address space access is performed based on the actual memory address of the accessed data.
7. The method of claim 3, wherein, The space type is determined to be a memory space, which comprises: If the memory address is less than the size of the read-only variable region in the module information of the target module, it is determined that the memory address points to the heap region of module read-only data. If the memory address is greater than or equal to the size of the read-only variable region in the module information of the target module, it is determined that the memory address points to the module global data memory region.
8. The method of claim 3, wherein, Further comprising: determining an access space type according to the module information of the target module and the memory address; in a case where it is determined that the access space type is an indirect access variable stack, obtaining an actual memory address of the current indirect access variable stack; performing address space access according to the actual memory address of the current indirect access variable stack.
9. The method of claim 8, wherein, The determination that the access space type is an indirect access variable stack comprises: if the memory address is greater than or equal to the size of the global variable region in the module information of the target module, it is determined that the memory address points to the indirect access variable stack.
10. The method of claim 8, wherein, The address space access according to the actual memory address of the current indirect access variable stack comprises: obtaining an actual physical memory space of the current indirect access variable stack; on the basis of the highest address value of the actual physical memory space, offsetting the memory address relative to a set maximum space limit value of the indirect access variable stack to a low address to locate the actual memory address of the current indirect access variable stack; or on the basis of the starting address of the actual physical memory space, offsetting the memory address relative to a set base address of the indirect access variable stack to locate the actual memory address of the current indirect access variable stack; performing address space access based on the actual memory address of the current indirect access variable stack.
11. The method of claim 1, wherein, The establishment of the module memory link of all modules imported by the currently selected application comprises: when an application is selected, finding all other modules imported by the module code in which the currently selected application is located, and recording all module information imported; when an application is selected, sequentially allocating memory spaces to the recorded imported modules and the module in which the currently selected application is located, and recording allocated memory space information; establishing an association between the module information and the memory space information allocated to the module to obtain information of the module memory link.
12. The method of claim 1, wherein, The establishment of the module memory link of all modules imported by the currently selected application comprises: accessing module information to find the information of the module memory link; wherein the module information comprises module management information or NVM space.
13. The method of claim 12, wherein, Before the accessing of the module management information to find the module memory link, further comprising: determining a target generation mode of the memory link of the module to which the application belongs according to an application publishing mode; generating the information of the module memory link of the application by using the target generation mode.
14. The method of claim 13, wherein, The application publishing mode comprises a post-download application; and the generation of the information of the module memory link of the application by using the target generation mode comprises: in a binary executable file downloading process of the post-download application, generating information of logical allocation of memory spaces of each module according to information of all modules imported by an import section of the binary executable file. The memory space allocation information of each module is stored into the module information of the current downloaded module.
15. The method of claim 13, wherein, The application publishing mode includes a preset application; and the information of the module memory link of the application generated by using the target generation mode includes: In the process of generating the mask file, the information of the logical allocation of the memory space of each module imported by the application module import section is generated; The information of the memory space allocation of each module is outputted to the mask file as the generation data of the module information.
16. The method according to claim 14 or 15, characterized in that, The information of the memory space allocation of each module includes: Global section information of the module is acquired, and the size of the global data of the global section module is calculated; The module global data is allocated with memory space, and the information of the first memory space allocation is recorded; The global local variables of all imported modules are allocated with memory space, and the information of the second memory space allocation is recorded.
17. A run-time memory management apparatus, characterized by, It includes: A module memory link establishment module is configured to, when an application is selected, call an entry function of the current selected application, and establish module memory links of all modules imported by the current selected application; A first memory address resolution module is configured to, when the current selected application code is executed, in a bytecode processing process corresponding to a virtual machine executing a target memory instruction to access a memory address, resolve the memory address obtained by preliminary resolution of the bytecode, to obtain module information and a memory type of a target module accessed by the memory; A start address determination module is configured to determine a start address of an actual memory space of the target module according to the module information and the memory type of the target module and the module memory links; An address space access module is configured to perform address space access according to the start address of the actual memory space of the target module.
18. An operating system, characterized by The operating system executes a runtime environment, and the operating system executes the runtime memory management method in any one of claims 1-16 through the runtime environment.
19. A virtual machine, comprising: The virtual machine runs on an operating system, and the operating system executes a runtime environment, and the operating system executes the runtime memory management method in any one of claims 1-16 through the runtime environment.
20. An electronic device, comprising: The electronic device includes an operating system in claim 18, and the electronic device includes: At least one processor; and A memory in communication connection with the at least one processor; wherein The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute the runtime memory management method in any one of claims 1-16.
21. The electronic device of claim 20, wherein, The electronic device includes a resource-constrained device.
22. The electronic device of claim 21, wherein, The resource-constrained device includes a smart card, a secure element SE, a secure chip, or an embedded device.
23. A terminal, characterized by The electronic device includes any one of claims 20-22.
24. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer instructions for enabling the processor to implement the runtime memory management method in any one of claims 1-16 when executed. The computer readable storage medium stores computer instructions for enabling the processor to implement the runtime memory management method in any one of claims 1-16 when executed.
25. A computer program product, characterised in that, The computer program product comprises a computer program which, when executed by a processor, implements the run-time memory management method according to any one of claims 1-16. The computer program product comprises a computer program which, when executed by a processor, implements the run-time memory management method according to any one of claims 1-16.