Virtual machine linear memory expansion method and device, storage medium and electronic equipment

Abstract

The application provides a virtual machine linear memory expansion method and device, a storage medium and electronic equipment, and applies to the technical field of virtual machine memory. When an application is started, a software development kit is initialized, and a preset capacity of a memory linear allocator corresponding to a system version is obtained. A memory mapping file of the SDK is parsed, a memory region range is determined, and a local method is called to find a memory starting address. According to the address, the memory linear allocator is expanded, and a target buffer is allocated by using a memory mapping function. The application effectively solves the problem of virtual machine method number limitation by improving the memory capacity, ensures stable operation in all scenarios including startup and runtime dynamic loading, and reduces the situation of crash and installation failure.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of virtual machine memory, and particularly relates to a virtual machine linear memory expansion method and device, a storage medium and an electronic device. BACKGROUND

[0002] Before Android 5.0, Android uses Dalvik virtual machine (Dalvik VM) to manage application memory, and uses memory linear allocator (LinearAlloc) to store classes and methods. Dalvik can contain at most 65535 methods in each DEX file, and exceeding the limit will cause memory shortage, installation failure or application crash. This brings challenges to large-scale application development.

[0003] Although the existing MultiDex technology solves the limitation of 65535 methods in each DEX file of Dalvik by splitting a single DEX file into multiple smaller DEX files, there are still limitations such as limiting file size, increasing development cost and runtime loading problems.

[0004] Therefore, how to effectively deal with the LinearAlloc memory limit in all scenarios has become a technical problem that technicians in the field urgently need to solve. SUMMARY

[0005] In view of the above problems, the present application provides a virtual machine linear memory expansion method, device, storage medium and electronic device which overcome the above problems or at least partially solve the above problems, and the technical solutions are as follows:

[0006] A virtual machine linear memory expansion method comprises:

[0007] In the case of starting an application program in a target operating system, initializing a software development kit of the application program, and obtaining a preset memory capacity of a memory linear allocator corresponding to a system version number of the target operating system, wherein the memory linear allocator is a module for managing memory allocation when loading classes in a virtual machine;

[0008] Reading and parsing a memory mapping file in the software development kit to determine a memory region range containing the memory linear allocator;

[0009] In the memory region range, calling a native method to find a memory mapping start address of the memory linear allocator;

[0010] Based on the memory mapping start address, performing memory expansion on the memory linear allocator according to the preset memory capacity;

[0011] allocating a target buffer to the memory linear allocator after memory expansion by using a memory mapping function, so that the virtual machine uses the target buffer for class loading operations.

[0012] Optionally, the reading and parsing the memory mapping file in the software development kit to determine the memory region range containing the memory linear allocator comprises:

[0013] reading and parsing the memory mapping file in the software development kit to obtain a parsing result list, wherein the parsing result list comprises a plurality of memory mapping information, and each piece of memory mapping information records a memory mapping start address, a memory mapping end address, a mapping region file name, and readability information;

[0014] searching for the memory region range containing the memory linear allocator in the parsing result list.

[0015] Optionally, the calling a native method to find the memory mapping start address of the memory linear allocator in the memory region range comprises:

[0016] calling a native method by using a native interface to find the memory mapping start address of the memory linear allocator in the memory region range according to the offset corresponding to the system version number and the verification logic.

[0017] Optionally, the method further comprises:

[0018] in the case that the memory mapping start address of the memory linear allocator cannot be found in the memory region range, scanning out the memory mapping start address of the memory linear allocator in the heap memory of the virtual machine.

[0019] Optionally, the memory expansion of the memory linear allocator according to the preset memory capacity based on the memory mapping start address comprises:

[0020] determining whether the preset memory capacity is an integer multiple of the page size corresponding to the application program, if yes, expanding the memory size of the memory linear allocator to the preset memory capacity based on the memory mapping start address, and if no, adjusting the preset memory capacity to a target memory capacity which is an integer multiple of the page size corresponding to the application program, and expanding the memory size of the memory linear allocator to the target memory capacity based on the memory mapping start address, wherein the target memory capacity is greater than the preset memory capacity.

[0021] Optionally, after the allocating a target buffer to the memory linear allocator after memory expansion by using a memory mapping function, the method further comprises:

[0022] allocating a write reference count for each memory page in the target buffer and initializing the write reference count to a medium value.

[0023] Optionally, after the target buffer is allocated to the memory linear allocator after the memory is expanded using the memory mapping function, the method further comprises:

[0024] locking the target buffer using a mutex function;

[0025] replacing the original buffer of the memory linear allocator in the virtual machine with the target buffer while the target buffer is in the locked state and maintaining a current allocation offset;

[0026] after the replacement is completed, unlocking the target buffer so that the target buffer is in an unlocked state.

[0027] A virtual machine linear memory expansion apparatus, comprising an initialization unit, a memory region range determination unit, a memory mapping starting address finding unit, a memory expansion unit and a buffer allocation unit,

[0028] The initialization unit is configured to initialize a software development kit of an application program in a target operating system when the application program is started, and obtain a preset memory capacity of a memory linear allocator corresponding to a system version number of the target operating system, wherein the memory linear allocator is a module for managing memory allocation during class loading in a virtual machine.

[0029] The memory region range determination unit is configured to read and parse a memory mapping file in the software development kit, and determine a memory region range containing the memory linear allocator.

[0030] The memory mapping starting address finding unit is configured to call a local method to find a memory mapping starting address of the memory linear allocator in the memory region range.

[0031] The memory expansion unit is configured to perform memory expansion on the memory linear allocator according to the preset memory capacity based on the memory mapping starting address.

[0032] The buffer allocation unit is configured to allocate a target buffer to the memory linear allocator after the memory is expanded using a memory mapping function, so that the virtual machine uses the target buffer for class loading operation.

[0033] A computer readable storage medium having a program stored thereon, wherein the program is executed by a processor to implement the virtual machine linear memory expansion method according to any one of the preceding embodiments.

[0034] An electronic device comprises at least one processor, at least one memory connected with the processor via a bus, wherein the processor, the memory and the bus complete mutual communication; the processor is used to call program instructions in the memory to execute the virtual machine linear memory expansion method.

[0035] By the above technical solution, the virtual machine linear memory expansion method, device, storage medium and electronic device provided by the application can initialize the software development kit of the application program under the condition that the application program in the target operating system is started, obtain the preset memory capacity of the memory linear allocator corresponding to the system version number of the target operating system, wherein the memory linear allocator is a module for managing memory allocation when class loading in the virtual machine; read and analyze the memory mapping file in the software development kit to determine the memory region range containing the memory linear allocator; in the memory region range, call the local method to find the memory mapping start address of the memory linear allocator; based on the memory mapping start address, perform memory expansion on the memory linear allocator according to the preset memory capacity; use the memory mapping function to allocate the target buffer to the memory linear allocator after memory expansion, so that the virtual machine uses the target buffer for class loading operation. The application improves the memory capacity of the memory linear allocator, avoids the problem of virtual machine method number limitation, and also ensures that memory can be effectively managed in all scenarios including startup and runtime dynamic loading, so that large-scale application programs can be stably run, and the situation of crash and installation failure is reduced.

[0036] The above description is only a summary of the technical solution of the application. In order to make the technical means of the application more clear, the application can be implemented according to the content of the specification, and in order to make the above and other purposes, characteristics and advantages of the application more obvious and easy to understand, the following specific embodiments of the application are described. BRIEF DESCRIPTION OF DRAWINGS

[0037] By reading the detailed description of the preferred embodiments below, various other advantages and benefits will become clear to those of ordinary skill in the art. The drawings are only for the purpose of illustrating the preferred embodiments and are not considered as limiting the application. Moreover, the same reference symbols are used to represent the same parts throughout the drawings. In the drawings:

[0038] Figure 1 A flowchart of an embodiment of the virtual machine linear memory expansion method provided by the embodiment of the application is shown;

[0039] Figure 2 A logic block diagram of the virtual machine linear memory expansion method provided by the embodiment of the application is shown;

[0040] Figure 3A structural schematic diagram of a virtual machine linear memory expansion device provided by an embodiment of the present application is shown.

[0041] Figure 4 A structural schematic diagram of an electronic device provided by an embodiment of the present application is shown. DETAILED DESCRIPTION

[0042] Exemplary embodiments of the present application will be described in detail with reference to the drawings. Although exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the application to those skilled in the art.

[0043] In system versions prior to Android 5.0, Android mainly uses Dalvik Virtual Machine (Dalvik VM) as the runtime environment. Dalvik VM is responsible for managing the memory allocation and execution of applications, however, its memory management method has some limitations, especially when dealing with large-scale code. Dalvik VM uses a memory area called LinearAlloc, which is used to store classes, methods and related metadata.

[0044] When an application is installed, Dalvik VM needs to decompress and load the code in the APK file and allocate memory space. The code file format in the APK file is DEX (Dalvik Executable), which is designed to optimize memory occupation and running efficiency. Generally, the default size of LinearAlloc is 5MB to 8MB, depending on the Android version.

[0045] However, there is an important bottleneck in Dalvik's memory allocation mechanism, that is, each DEX file can contain at most 65535 methods. When the number of methods in the code of an application exceeds this limit, Dalvik VM is prone to run out of memory when loading these codes. Due to the limited size of LinearAlloc, code with more than 65535 methods will cause the following problems:

[0046] Installation failure: During installation, if the number of methods in the DEX file exceeds the LinearAlloc limit, the system cannot allocate enough memory space for it, resulting in application installation failure.

[0047] Application crash: During application runtime, if the code that triggers the loading of more than the method limit is triggered, Dalvik VM cannot dynamically allocate more memory for it, which may cause an OutOfMemoryError error, resulting in application crash or forced exit.

[0048] These limitations pose a significant challenge to modern application development, especially as applications grow in size and become more complex, developers frequently encounter the problem of insufficient LinearAlloc memory.

[0049] To address this issue, existing technical solutions primarily rely on the MultiDex library provided by Google to indirectly address the 65,535-method limit when installing APKs using the Dalvik virtual machine. MultiDex technology splits a single DEX file containing a large number of methods into multiple smaller DEX files. The size and number of methods in each file remain within Dalvik's limits, thus avoiding memory exhaustion or crashes caused by exceeding the method limit.

[0050] Although MultiDex has solved the problem of exceeding 65535 methods to some extent, i.e., the APK installation error, this technical solution still has the following limitations:

[0051] DEX file size limitations: Although applications can be subdivided, each DEX file is still limited by Dalvik's maximum number of methods (65,535), requiring developers to pay extra attention to code allocation. Typically, developers need to meticulously divide the classes and methods in their application and control the size of each DEX file through configuration files (e.g., limiting each DEX file to under 2MB) to avoid exceeding the method limit.

[0052] Increased development costs: Developers must manually adjust the classes and methods that should be included in each DEX file, which complicates the development process. This is especially true for large or frequently updated projects, where maintaining a code sub-package structure adds an extra workload.

[0053] While MultiDex can dynamically load multiple DEX files at application startup, it may still trigger method count exceeding issues in certain scenarios during application runtime. For example, in a plugin-based solution, external plugin DEX files may be loaded at runtime, potentially exceeding 65535 methods, causing Dalvik to fail to load the plugin and crash. Similarly, dynamic hot-update technology may still face method count exceeding issues when loading new DEX files at runtime if the DEX file size is not strictly controlled.

[0054] In summary, while MultiDex provides a solution to the method count limitation of the Dalvik virtual machine, it has limitations in flexibility, maintainability, and performance. Especially in scenarios where DEX files are dynamically loaded at runtime, the 65535 method count limit cannot be completely avoided. Therefore, existing technologies cannot effectively address the LinearAlloc memory limit in all scenarios. To solve this problem, it is necessary to propose a new method that can dynamically expand the size of LinearAlloc in older Android versions (those using the Dalvik VM), thereby overcoming Dalvik's memory limitations and enabling large-scale application code to load and run smoothly, reducing application crashes or installation failures.

[0055] Based on this, this embodiment of the invention provides a method for expanding the linear memory of a virtual machine. First, when the application is started in the target operating system, the software development kit (SDK) is initialized, and the preset memory capacity of the memory linear allocator corresponding to the system version number is obtained. Second, the memory mapping file in the SSD is read and parsed to determine the memory region range of the memory linear allocator. Then, within this range, a native method is called to find the starting address of the memory mapping. Based on the starting address, the memory linear allocator is expanded according to the preset memory capacity. Finally, a memory mapping function is used to allocate a target buffer for the expanded memory linear allocator, allowing the virtual machine to use this buffer during class loading operations. It is evident that this embodiment of the invention, by increasing the memory capacity, avoids the limitation on the number of virtual machine methods, ensuring the effectiveness of memory management in all scenarios, including startup and dynamic loading during runtime, enabling large-scale applications to run stably and reducing crashes and installation failures.

[0056] like Figure 1 The diagram shows a flowchart of one embodiment of the virtual machine linear memory expansion method provided by this invention. The method may include:

[0057] S100. When the application starts in the target operating system, initialize the application's software development kit and obtain the preset memory capacity of the memory linear allocator corresponding to the system version number of the target operating system. The memory linear allocator is a module that manages memory allocation when classes are loaded in the virtual machine.

[0058] The target operating system can refer to a mobile phone operating system, which is the basic software that manages the hardware and software resources of a mobile phone. For example, the Android operating system.

[0059] Applications are installed on the operating system to provide users with specific functions and services. Examples include social media apps, games, and office software. Applications rely on the resources and services provided by the operating system to run.

[0060] The Software Development Kit (SDK) is a set of tools, libraries, sample code, and documentation for building software applications. This invention, through its SDK interface, allows developers to easily call memory expansion functions without manually modifying the underlying code of the Android system or virtual machine, thereby reducing development workload and improving development efficiency.

[0061] The linear memory allocator is a module that manages metadata in the virtual machine, including class definitions, method definitions, and field information, using a linear allocation strategy. This metadata needs to be loaded into memory at application runtime for use by the virtual machine. For example, LinearAlloc manages memory allocation in the Dalvik virtual machine of the Android operating system.

[0062] Specifically, in this embodiment of the invention, the initialization method provided by the SDK can be called at the application startup entry point of the main thread when the application starts. During SDK initialization, the corresponding LinearAlloc buffer size is passed in according to different Android versions. For example, for Android 2.3 (Gingerbread) and Android 4.0 (Ice Cream Sandwich), it is recommended to expand the buffer to 16MB; for other versions, different memory sizes should be configured according to specific needs.

[0063] S110. Read and parse the memory-mapped file in the software development kit to determine the range of the memory region containing the memory linear allocator.

[0064] The memory-mapped file is a virtual file in the Linux system that displays the memory mapping information of the current process. This file contains detailed mapping information of the process's address space, including the start and end addresses, permissions, offsets, devices, nodes, and the filenames to which each memory segment is mapped.

[0065] S120. Within the memory region, call a native method to find the starting address of the memory mapping of the memory linear allocator.

[0066] The memory mapping start address of the memory linear allocator refers to the starting position of the memory linear allocator's mapping in the process's address space. This address marks the starting point of the memory region managed by the memory linear allocator. It is used to control and manage the memory allocation process, ensuring the effectiveness and security of memory usage. When using memory mapping, the system allocates and manages memory based on this start address.

[0067] S130. Based on the memory mapping start address, expand the memory linear allocator according to the preset memory capacity.

[0068] This invention allows for the allocation of a new contiguous block of memory by the linear memory allocator during memory expansion, and its connection to the current linear memory allocator's memory region. By dynamically expanding the LinearAlloc buffer, this invention can increase memory allocation to a larger extent, thereby significantly reducing the risk of application crashes due to insufficient memory, especially when loading a large number of classes.

[0069] S140. Use the memory mapping function to allocate the target buffer to the extended memory linear allocator so that the virtual machine can use the target buffer for class loading operations.

[0070] Among them, the Memory Map (MMAP) function is used to establish a mapping between files or devices and memory in a process's address space. Memory mapping uses anonymous mapping to create new memory regions, managing memory allocation more efficiently and avoiding performance bottlenecks and memory waste that exist in traditional methods.

[0071] This invention allocates a new buffer for LinearAlloc by calling the mmap function and creates this region in memory using anonymous mapping. This allows for custom-sized memory allocations, such as up to 16MB.

[0072] Anonymous mapping is a memory mapping method created using the mmap function. The mapped memory region is not associated with the actual file system. This mapped region is used only in memory and is not swapped with disk. This invention creates a new LinearAlloc buffer through anonymous mapping, ensuring that its allocation is independent of the file system, thereby improving the efficiency and flexibility of memory management.

[0073] This invention provides a method for expanding the linear memory of a virtual machine. The method includes: when an application starts in a target operating system, initializing the application's software development kit (SDK) and obtaining a preset memory capacity for a memory linear allocator corresponding to the system version number of the target operating system. The memory linear allocator is a module in the virtual machine that manages memory allocation during class loading. The method also includes: reading and parsing a memory mapping file in the SSD to determine the memory region containing the memory linear allocator; within the memory region, calling a native method to find the starting address of the memory mapping for the memory linear allocator; expanding the memory linear allocator according to the preset memory capacity based on the starting address; and using a memory mapping function to allocate a target buffer to the expanded memory linear allocator, enabling the virtual machine to use the target buffer for class loading operations. This invention, by increasing the memory capacity of the memory linear allocator, avoids the problem of virtual machine method number limitations and ensures effective memory management in all scenarios, including startup and runtime dynamic loading, enabling large-scale applications to run stably and reducing crashes and installation failures.

[0074] Optionally, in the above Figure 1 Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, reading and parsing the memory mapping file in the software development kit to determine the memory region range containing the memory linear allocator may specifically include:

[0075] Read and parse the memory-mapped files in the software development kit to obtain a list of parsing results. The list of parsing results includes multiple memory mapping information entries. Each memory mapping information entry records the memory mapping start address, memory mapping end address, mapped region file name, and readability information. Search the parsing results list to find the memory region range containing the memory linear allocator.

[0076] Specifically, during SDK initialization, this embodiment of the invention can read and parse the memory-mapped file " / proc / self / maps", which contains all memory-mapped information for the current process. After parsing, a parsing result list is generated. Each item in the parsing result list describes a piece of memory-mapped information, recording the memory-mapped start address, memory-mapped end address, mapped region filename, and its readability. Next, this embodiment of the invention searches the parsing result list for all memory regions containing "LinearAlloc" to obtain the starting address of the LinearAlloc region in the Dalvik virtual machine.

[0077] Understandably, parsing memory-mapped files can provide a general outline of the memory region for the linear allocator. However, this region may contain multiple memory blocks with different purposes. This information alone is insufficient to determine the exact starting address of the LinearAlloc region. Furthermore, a memory region may contain multiple different memory allocators or other metadata. The address range obtained by parsing memory-mapped files may not be entirely accurate, as it may include other unrelated memory regions. Moreover, memory management in the Android system and Dalvik virtual machine is dynamic; the size and location of memory regions may change as the application runs. Relying solely on static memory-mapped file information is insufficient to handle such dynamic changes.

[0078] Therefore, in order to accurately locate the specific starting address of the LinearAlloc region, the SDK needs to analyze the memory layout more deeply to ensure that it has indeed found the starting address of the LinearAlloc region.

[0079] Optionally, in the above Figure 1 Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, in the memory region, calling a native method to find the starting address of the memory mapping of the memory linear allocator may specifically include:

[0080] Using the local interface to call the local method, based on the offset corresponding to the system version number and the verification logic, the starting address of the memory mapping of the memory linear allocator is found in the memory region.

[0081] Specifically, embodiments of the present invention can use JNI (Java Native Interface) to call the native method `nativeFindLinearAllocHeader` to directly access the underlying memory and perform more detailed checks and analyses to determine the memory mapping start address of `LinearAlloc`. JNI is an interface between Java and native code (such as C / C++) used to call underlying native methods in Android applications. In this invention, JNI is used to call native methods from Java code to find and replace the `LinearAlloc` buffer in the Dalvik virtual machine. The native method `nativeFindLinearAllocHeader`, depending on the Android version, uses corresponding offsets and verification logic to first attempt to locate the memory mapping start address of `LinearAlloc` in `gDvm`. If it is not found in `gDvm`, it scans the entire heap memory; that is, if the memory mapping start address of the linear allocator cannot be found within the memory region, it scans the virtual machine's heap memory to find the memory mapping start address of the linear allocator.

[0082] `gDvm` is a global structure of the Dalvik virtual machine, storing the virtual machine's core state and runtime information. During the search for the `LinearAlloc` memory, `gDvm` is used to quickly locate the entry point of that memory region. In some cases, it is necessary to extract the location of `LinearAlloc` from `gDvm` for further memory management operations. If the starting address of the `LinearAlloc` memory mapping is successfully found, execution continues to the next step; otherwise, an exception is thrown and the process terminates.

[0083] Heap memory is a part of computer memory used for dynamic memory allocation. The allocation and deallocation of heap memory are determined by operations performed during program execution and are typically handled by the programming language's memory manager (such as the garbage collector in Java).

[0084] The native method scans memory regions to find specific markers or structures, which can be characteristics of the LinearAlloc region. This allows for precise location of the starting address of the LinearAlloc region. Precise location avoids misidentifying other memory regions as LinearAlloc, thus improving the reliability of memory expansion.

[0085] To facilitate understanding, an example is provided: Suppose that parsing a memory-mapped file yields a memory region ranging from 0x1000 to 0x2000. This range may contain multiple memory blocks for different purposes, such as class definitions, method tables, and other metadata. By further calling `nativeFindLinearAllocHeader`, specific markers or structures can be scanned within this range, ultimately pinpointing 0x1500 as the exact starting address of the LinearAlloc region.

[0086] This invention provides an approximate range by parsing a memory-mapped file, and then uses JNI to call native methods for more refined memory scanning and matching. This enables precise location of the starting address of the memory mapping for LinearAlloc, thereby improving the accuracy of memory management and operations and avoiding potential misjudgments and memory management problems.

[0087] Optionally, in the above Figure 1 Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, the memory linear allocator is expanded according to a preset memory capacity based on the memory mapping start address, which may specifically include:

[0088] If the preset memory capacity is an integer multiple of the page size corresponding to the application, then the memory size of the memory linear allocator is expanded to the preset memory capacity based on the memory mapping start address. If not, the preset memory capacity is adjusted to the target memory capacity, which is an integer multiple of the page size corresponding to the application, and the memory size of the memory linear allocator is expanded to the target memory capacity based on the memory mapping start address, wherein the target memory capacity is greater than the preset memory capacity.

[0089] Specifically, in this embodiment of the invention, the memory size of LinearAlloc can be adjusted according to the obtained Android version configuration. For example, in Android 2.3, the default LinearAlloc buffer size is 8MB, which can be expanded to 16MB using parameters passed from the SDK. In Android 4.0, the default LinearAlloc buffer size is also 8MB, and it can also be expanded to 16MB. The expanded memory size of LinearAlloc will be adjusted according to the page size (systemPageSize) to ensure that the memory size is an integer multiple of the page size.

[0090] Understandably, once the starting address of LinearAlloc is determined, it typically remains unchanged during program execution. Even when memory is expanded, the new memory block is added to the end of the original memory region, rather than changing the starting address. This ensures the consistency of the memory region and helps simplify memory management. During memory expansion, a new contiguous block of memory is allocated and connected to the current LinearAlloc region. All new memory addresses after the expansion are still calculated based on the original starting address. For example, if the starting address is 0x1000, and the expanded memory starts at 0x2000, then the newly allocated memory addresses are still calculated and managed relative to 0x1000. Boundary checks (such as preventing out-of-bounds access) are required during memory operations. These checks are typically based on the starting address and the total size of allocated memory. After memory expansion, the total size is updated, but the starting address remains unchanged, which helps keep the boundary check logic simple and consistent.

[0091] To facilitate understanding, an example is provided below: Assume the starting address of the LinearAlloc region is 0x1000, and its size is 0x1000 (4KB). Initially, the memory allocation range is from 0x1000 to 0x2000. After expansion, assume the new memory block is from 0x2000 to 0x3000 (an additional 4KB). At this point, the original starting address 0x1000 remains unchanged, but the total LinearAlloc memory range is now from 0x1000 to 0x3000.

[0092] It's important to note that because the system manages memory in pages, the allocated memory size must be an integer multiple of the page size; this is also known in the field as "page alignment" or "alignment to page boundaries." For example, if the page size is 4KB, then the allocated memory should be 4KB, 8KB, 12KB, etc. If 6KB needs to be allocated, the system will actually allocate 8KB to ensure that the memory is an integer multiple of the page size.

[0093] This invention adjusts the memory capacity to an integer multiple of the page size, which helps simplify the memory management process, reduce the complexity of memory management, and make it easier for the operating system to perform memory allocation and reclamation operations. At the same time, ensuring that the preset memory capacity is aligned with the page size helps avoid potential memory access errors and anomalies, guarantees the stability and reliability of the system after memory expansion, and improves the compatibility and adaptability of programs on different platforms after memory expansion.

[0094] Optionally, in the above Figure 1 Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, after allocating the target buffer to the memory-expanded linear allocator using the memory mapping function, the method may further include:

[0095] Assign a write reference count to each memory page in the target buffer and initialize the write reference count to a medium value.

[0096] Specifically, after the SDK allocates the target buffer to the extended memory linear allocator using the memory mapping function, it allocates a write reference count (writeRefCount) for each memory page and initializes it to a medium value (SHRT_MAX / 2) to prevent overflow or underflow during the allocation process.

[0097] In this context, "medium value" refers to a constant in C / C++ representing the maximum value of a short integer, typically used to initialize memory counters. In this invention, half of SHRT_MAX (SHRT_MAX / 2) is used to initialize writeRefCount to prevent memory reference count overflow or underflow.

[0098] The write reference count is a reference count array used in the Dalvik virtual machine to manage write operations on LinearAlloc memory pages. In this invention, this reference count array is reallocated for the new LinearAlloc buffer and initialized to half of SHRT_MAX (SHRT_MAX / 2) to accommodate the possible enabling of the ENFORCE_READ_ONLY mode. ENFORCE_READ_ONLY is a mechanism in the Dalvik virtual machine used to force certain memory regions to be read-only. On some devices, ENFORCE_READ_ONLY may be enabled, affecting modifications to the LinearAlloc buffer. This invention ensures that LinearAlloc can still be expanded even when this mechanism is enabled by handling writeRefCount.

[0099] Optionally, in the above Figure 1 Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, after allocating the target buffer to the memory-expanded linear allocator using the memory mapping function, the method may further include:

[0100] The target buffer is locked using a mutex function; while the target buffer is locked, the original buffer of the memory linear allocator in the virtual machine is replaced with the target buffer, while maintaining the current allocation offset; after the replacement is complete, the target buffer is unlocked to make it unlocked.

[0101] This invention embodiment uses the mutex functions "pthread_mutex_lock" and "pthread_mutex_unlock" to protect the replacement operation of the LinearAlloc buffer, preventing data inconsistency caused by concurrent access by multiple threads and ensuring thread safety. Then, the LinearAlloc buffer in the Dalvik virtual machine is replaced. The replacement process includes replacing the old LinearAlloc address in the Dalvik virtual machine with the new mapAddr. The currently allocated memory offset (curOffset) remains unchanged so that the new buffer continues to utilize the remaining space of the old buffer, thereby avoiding impact on existing memory. Finally, the mutex is unlocked, completing the replacement of the LinearAlloc buffer. After the replacement, the Dalvik virtual machine can use the new, larger LinearAlloc buffer, ensuring that existing allocations are unaffected. The SDK's extended memory task provides more memory space for Dalvik's class loading operations. This invention embodiment, based on the memory structure changes of different Android versions, employs flexible offset adjustment and memory scanning techniques to ensure successful location and replacement of the LinearAlloc buffer on all versions. When replacing the LinearAlloc buffer, the original allocation location and state are maintained to ensure that the allocated memory is not lost or data errors occur, making the expansion process transparent to the application.

[0102] The memory offset records the memory location already allocated to LinearAlloc, and new memory allocation will continue from this offset. In this invention, when replacing the LinearAlloc buffer, curOffset is preserved so that unused space in the old buffer can continue to be used.

[0103] To facilitate understanding of the overall logic of the virtual machine linear memory expansion method provided in this embodiment of the invention, this section combines... Figure 2 For example: Figure 2The diagram shows the logical block diagram of the virtual machine linear memory expansion method provided in this embodiment of the invention. This method can be applied to a software development kit (SDK) to dynamically expand the LinearAlloc buffer of the Dalvik virtual machine in the Android system to solve its memory limitation problem. The SDK is invoked when the application starts, parsing the ` / proc / self / maps` file to find the memory mapping information of the LinearAlloc region in the Dalvik virtual machine and obtain its starting address. To more accurately locate LinearAlloc, the SDK further processes it by calling a native method. The native method first attempts to find the starting address of LinearAlloc in the Dalvik global variable `gDvm`. If it is not found in `gDvm`, the code continues to scan the entire heap memory region, adjusting relevant offsets based on different Android system versions and checking the start and end addresses of the heap memory to ensure accurate location of the LinearAlloc region. Once the starting memory address of LinearAlloc is successfully obtained, the SDK creates a new LinearAlloc buffer according to the Android system version. For example, in Android 4.0, the SDK uses anonymous memory mapping (mmap) to create a new 16MB buffer (previously 8MB). Then, the SDK replaces the existing LinearAlloc buffer in the Dalvik virtual machine with the newly allocated buffer while keeping the current memory allocation unaffected. To ensure compatibility and security, the SDK uses locking operations to guarantee thread safety during the replacement process and updates and initializes the metadata of LinearAlloc (such as mapAddr and writeRefCount). In this way, the present invention effectively expands the original linear memory limit of the Dalvik virtual machine, providing more memory space for Android applications, thereby reducing the risk of crashes due to insufficient memory and improving application stability and performance.

[0104] Although the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous.

[0105] It should be understood that the various steps described in the method embodiments of the present invention may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present invention is not limited in this respect.

[0106] Corresponding to the above method embodiments, this invention also provides a virtual machine linear memory expansion device, the structure of which is as follows:Figure 3 As shown, it may include: an initialization unit 10, a memory region range determination unit 20, a memory mapping start address lookup unit 30, a memory expansion unit 40, and a buffer allocation unit 50.

[0107] Initialization unit 10 is used to initialize the application's software development kit when the application starts in the target operating system, and obtain the preset memory capacity of the memory linear allocator corresponding to the system version number of the target operating system. The memory linear allocator is a module that manages memory allocation when classes are loaded in the virtual machine.

[0108] The memory region range determination unit 20 is used to read and parse the memory mapping file in the software development kit to determine the memory region range containing the memory linear allocator.

[0109] The memory mapping start address lookup unit 30 is used to call a native method to find the memory mapping start address of the memory linear allocator within the memory region.

[0110] The memory expansion unit 40 is used to expand the memory linear allocator according to a preset memory capacity based on the memory mapping start address.

[0111] The buffer allocation unit 50 is used to allocate a target buffer to the memory linear allocator after memory expansion using a memory mapping function, so that the virtual machine can use the target buffer to perform class loading operations.

[0112] Optionally, the memory region range determination unit 20 can be specifically used to read and parse the memory mapping file in the software development kit to obtain a parsing result list. The parsing result list includes multiple memory mapping information entries, each of which records the memory mapping start address, memory mapping end address, mapping region file name, and readability information. The memory region range containing the memory linear allocator is searched in the parsing result list.

[0113] Optionally, the memory mapping start address lookup unit 30 can be specifically used to call a local method using a local interface, and search for the memory mapping start address of the memory linear allocator in the memory region based on the offset corresponding to the system version number and the verification logic.

[0114] Optionally, the memory mapping start address lookup unit 30 can also be specifically used to scan the memory mapping start address of the memory linear allocator in the virtual machine's heap memory when the memory mapping start address of the memory linear allocator cannot be found in the memory region.

[0115] Optionally, the memory expansion unit 40 can be specifically used to determine whether the preset memory capacity is an integer multiple of the page size corresponding to the application. If so, the memory size of the memory linear allocator is expanded to the preset memory capacity based on the memory mapping start address. If not, the preset memory capacity is adjusted to the target memory capacity, which is an integer multiple of the page size corresponding to the application, and the memory size of the memory linear allocator is expanded to the target memory capacity based on the memory mapping start address, wherein the target memory capacity is greater than the preset memory capacity.

[0116] Optionally, the virtual machine linear memory expansion device may further include a write reference count setting unit.

[0117] The write reference count setting unit is used by the buffer allocation unit 50 to allocate the target buffer to the memory linear allocator after the memory is expanded using the memory mapping function, to allocate a write reference count to each memory page in the target buffer, and to initialize the write reference count to a medium value.

[0118] Optionally, the virtual machine linear memory expansion device may also include a thread protection unit.

[0119] The thread protection unit is used by the buffer allocation unit 50 to allocate a target buffer to the memory linear allocator after the memory is expanded using the memory mapping function, and then to lock the target buffer using the mutex lock function. While the target buffer is locked, the target buffer replaces the original buffer of the memory linear allocator in the virtual machine, while maintaining the current allocation offset. After the replacement is completed, the target buffer is unlocked to make it unlocked.

[0120] The virtual machine linear memory expansion device provided by this invention, when an application in the target operating system starts, initializes the application's software development kit (SDK) to obtain the preset memory capacity of the memory linear allocator corresponding to the system version number of the target operating system. The memory linear allocator is a module in the virtual machine that manages memory allocation during class loading. The device reads and parses the memory mapping file in the SSD to determine the memory region containing the memory linear allocator. Within the memory region, it calls a native method to find the memory mapping start address of the memory linear allocator. Based on the memory mapping start address, it expands the memory linear allocator according to the preset memory capacity. Finally, it uses a memory mapping function to allocate a target buffer to the expanded memory linear allocator, enabling the virtual machine to use the target buffer for class loading operations. This invention, by increasing the memory capacity of the memory linear allocator, avoids the problem of virtual machine method number limitations and ensures effective memory management in all scenarios, including startup and runtime dynamic loading, enabling large-scale applications to run stably and reducing crashes and installation failures.

[0121] Regarding the apparatus in the above embodiments, the specific manner in which each unit performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0122] The virtual machine linear memory expansion device includes a processor and a memory. The initialization unit 10, the memory region range determination unit 20, the memory mapping start address lookup unit 30, the memory expansion unit 40, and the buffer allocation unit 50 are all stored in the memory as program units. The processor executes the program units stored in the memory to implement the corresponding functions.

[0123] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured; by adjusting kernel parameters, the software development kit (SDK) is initialized at application startup, and the preset capacity of the memory linear allocator for the corresponding system version is obtained. The SDK's memory mapping file is parsed to determine the memory region range, and native methods are called to find the starting address of the memory. Based on this address, the memory linear allocator is expanded, and the target buffer is allocated using memory mapping functions. This method effectively solves the problem of virtual machine method number limitations by increasing memory capacity, ensuring stable operation in all scenarios, including startup and dynamic loading at runtime, thereby reducing crashes and installation failures.

[0124] This invention provides a computer-readable storage medium storing a program that, when executed by a processor, implements the virtual machine linear memory expansion method.

[0125] This invention provides a processor for running a program, wherein the program executes the virtual machine linear memory expansion method during runtime.

[0126] like Figure 4 As shown, this embodiment of the invention provides an electronic device 1000, which includes at least one processor 1001, at least one memory 1002 connected to the processor 1001, and a bus 1003. The processor 1001 and the memory 1002 communicate with each other via the bus 1003. The processor 1001 is used to call program instructions in the memory 1002 to execute the aforementioned virtual machine linear memory expansion method. The electronic device in this document can be a server, PC, PAD, mobile phone, etc.

[0127] The present invention also provides a computer program product that, when executed on an electronic device, is adapted to execute a program that initializes a virtual machine linear memory expansion method step.

[0128] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, electronic devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0129] In a typical configuration, an electronic device includes one or more processors (CPUs), memory, and a bus. The electronic device may also include input / output interfaces, network interfaces, etc.

[0130] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, like read-only memory (ROM) or flash RAM, and memory includes at least one memory chip. Memory is an example of computer-readable media.

[0131] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0132] In the description of this invention, it should be understood that if the terms "upper", "lower", "front", "rear", "left" and "right" are used to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the position or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention.

[0133] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0134] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0135] The above are merely embodiments of the present invention and are not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the claims of the present invention.

Claims

1. A method for linear memory enlargement of a virtual machine, characterized by, Comprise: In the case of application program startup in the target operating system, initialize the software development kit of the application program, obtain the preset memory capacity of the memory linear allocator corresponding to the system version number of the target operating system, wherein the memory linear allocator is a module for managing class loading memory allocation in a virtual machine; the memory linear allocator is LinearAlloc; Read and parse the memory mapping file in the software development kit to determine the memory region range containing the memory linear allocator; In the memory region range, call a native method to find the memory mapping start address of the memory linear allocator; Based on the memory mapping start address, perform memory expansion on the memory linear allocator according to the preset memory capacity; Use the memory mapping function mmap to allocate a target buffer to the memory-expanded memory linear allocator, and use anonymous mapping Anonymous Mapping to create the target buffer in memory, so that the virtual machine uses the target buffer for class loading operation.

2. The method of claim 1, wherein, The reading and parsing of the memory mapping file in the software development kit to determine the memory region range containing the memory linear allocator comprises: Read and parse the memory mapping file in the software development kit to obtain a parsing result list, wherein the parsing result list includes multiple memory mapping information, and each memory mapping information records a memory mapping start address, a memory mapping end address, a mapping region file name, and readability information; Search for the memory region range containing the memory linear allocator in the parsing result list.

3. The method of claim 1, wherein, The calling of a native method in the memory region range to find the memory mapping start address of the memory linear allocator comprises: Use a native interface to call a native method to find the memory mapping start address of the memory linear allocator in the memory region range according to the offset corresponding to the system version number and the verification logic.

4. The method of claim 3, wherein, Further comprise: In the case that the memory mapping start address of the memory linear allocator cannot be found in the memory region range, scan the memory mapping start address of the memory linear allocator in the heap memory of the virtual machine.

5. The method of claim 1, wherein, The memory expansion on the memory linear allocator according to the preset memory capacity based on the memory mapping start address comprises: Determine whether the preset memory capacity is an integer multiple of the page size corresponding to the application program, if yes, expand the memory size of the memory linear allocator to the preset memory capacity based on the memory mapping start address, if not, adjust the preset memory capacity to a target memory capacity which is an integer multiple of the page size corresponding to the application program, and expand the memory size of the memory linear allocator to the target memory capacity based on the memory mapping start address, wherein the target memory capacity is greater than the preset memory capacity.

6. The method of claim 1, wherein, After the use of the memory mapping function mmap to allocate a target buffer to the memory-expanded memory linear allocator, the method further comprises: A write reference count is assigned to each memory page in the target buffer, and the write reference count is initialized to a medium value.

7. The method of claim 1, wherein, After the target buffer is allocated to the memory linear allocator after memory expansion using the memory mapping function mmap, the method further comprises: A locking operation is performed on the target buffer using a mutex function; When the target buffer is in a locked state, the original buffer of the memory linear allocator in the virtual machine is replaced using the target buffer, and the current allocation offset is maintained; After the replacement is completed, the target buffer is unlocked to make the target buffer in an unlocked state.

8. A virtual machine linear memory enlargement apparatus, comprising: a memory controller, wherein the memory controller is configured to: receive a request to enlarge a memory of a virtual machine; and enlarge the memory of the virtual machine. Comprise: An initialization unit, a memory region range determination unit, a memory mapping start address finding unit, a memory expansion unit, and a buffer allocation unit; The initialization unit is configured to initialize a software development kit of an application program in a target operating system when the application program is started, obtain a preset memory capacity of a memory linear allocator corresponding to a system version number of the target operating system, wherein the memory linear allocator is a module for managing memory allocation during class loading in a virtual machine; and the memory linear allocator is LinearAlloc; The memory region range determination unit is configured to read and parse a memory mapping file in the software development kit, and determine a memory region range containing the memory linear allocator; The memory mapping start address finding unit is configured to find a memory mapping start address of the memory linear allocator in the memory region range by calling a local method; The memory expansion unit is configured to perform memory expansion on the memory linear allocator according to the preset memory capacity based on the memory mapping start address; The buffer allocation unit is configured to allocate a target buffer to the memory linear allocator after memory expansion using a memory mapping function mmap, and create the target buffer in memory using anonymous mapping Anonymous Mapping, so that the virtual machine performs class loading operation using the target buffer.

9. A computer-readable storage medium having stored thereon a program, characterized in that, The program is executed by the processor to implement the virtual machine linear memory expansion method in any one of claims 1 to 7.

10. An electronic device, comprising at least one processor, and at least one memory connected to the processor via a bus; wherein, The processor, the memory and the bus complete communication with each other; The processor is configured to call program instructions in the memory to execute the virtual machine linear memory expansion method in any one of claims 1 to 7. The processor, the memory and the bus complete communication with each other; The processor is configured to call program instructions in the memory to execute the virtual machine linear memory expansion method in any one of claims 1 to 7.

Images