Application-awareness-free memory longitudinal capacity expansion method
By analyzing the memory usage of Serverless applications, dynamically allocating and expanding memory blocks, and using the Cinvoke mechanism and LibOS management, the memory expansion difficulties during Serverless runtime under the CHERI architecture are solved, unconscious memory expansion is achieved, and resource utilization and scalability are improved.
Patent Information
- Application Number
- CN202410118557.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-01-29
- Publication Date
- 2025-07-29
AI Technical Summary
The serverless runtime of the prior art for CHERI architecture lacks an effective vertical memory expansion mechanism, which leads to difficulty in memory expansion and is unable to efficiently manage memory resources while maintaining isolation and performance.
By analyzing the historical memory usage of Serverless applications, dynamically allocate continuous memory blocks, and using the Cinvoke mechanism to trigger memory expansion when memory is insufficient, combining the LibOS memory management mechanism to initialize and register memory blocks to ensure memory continuity and security.
It realizes vertical memory expansion without perception, maintains the isolation and performance of Serverless applications, and improves resource utilization and scalability, avoiding cold start problems.
Smart Images
Figure CN120386613A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical fields of computer virtualization and cloud computing, and particularly to a method for vertically expanding memory without application awareness. Background Art
[0002] Serverless is a mainstream execution model in the current cloud computing field. Cloud service providers provide and manage server infrastructure, automatically allocate and scale resources, and developers only need to write and deploy applications or services without paying attention to the underlying server situation. In order to support multi-tenant use on a single server, Serverless, like other cloud services, needs to be deployed based on a certain isolation model.
[0003] Traditional Serverless isolation models in academia and industry can generally be summarized into the following three categories: lightweight virtual machines, secure containers, and language-level sandboxes. Different models have their own characteristics: lightweight virtual machines sacrifice compatibility but can provide excellent performance close to containers; secure containers balance isolation and compatibility but have a large performance loss; language-level sandboxes have high performance but provide low isolation.
[0004] CHERI (Capability Hardware Enhanced RISC Instructions) is an innovative computer hardware technology aimed at improving system security and reliability by enhancing the existing instruction set architecture. The CHERI architecture extends the pointer semantics in C / C++ by introducing a "Capability" structure to achieve hardware-level protection for a continuous memory segment. The new Serverless runtime solution uses the CHERI instruction set extension to meet the isolation requirements while maintaining high performance through a software-hardware collaborative approach using Capability, providing security protection, and achieving a new balance among the above three indicators, with great development potential.
[0005] Memory expansion is divided into horizontal and vertical. Currently, the mainstream Serverless expansion solution is mainly horizontal expansion, that is, increasing the number of Serverless instances to cope with high-load scenarios. The disadvantages are problems such as cold start and resource waste. Vertical expansion, on the other hand, is to increase the memory resources of a single Serverless instance, avoiding cold start while maintaining the original operating environment, with performance advantages. However, it brings an additional burden to resource management and scheduling, and currently, there is no vertical expansion mechanism for the Serverless runtime facing the CHERI architecture.
[0006] In the current design of the Serverless runtime under the CHERI architecture, first, a protected continuous memory isolation domain called Capability Virtual Machine (CVM) is constructed based on capabilities. On top of the isolation domain, a library operating system (LibOS) is run as the operating environment for Serverless applications, and a cross-domain call mechanism Cinvoke is provided to switch from within the isolation domain to the Serverless runtime. LibOS reuses some code of the Linux operating system but is more concise and efficient to meet the high-performance requirements of the Serverless scenario. However, it also poses new requirements for memory management, especially memory expansion: 1) The capability mechanism protects continuous memory, and the expanded memory should still remain continuous; 2) Different from Linux, LibOS cannot automatically recognize newly added memory and requires additional memory recognition and registration operations; 3) LibOS simplifies memory management and does not support the paged virtual memory scheme of traditional Linux operating systems. Summary of the Invention
[0007] In view of this, the present invention proposes a method for vertically expanding memory without application awareness to solve the problems in the prior art that the vertical memory expansion mechanism for the CHERI architecture is not yet perfect and memory expansion is difficult.
[0008] The specific technical solution of the present invention is as follows:
[0009] A method for vertically expanding memory without application awareness, comprising the following steps:
[0010] Step 1: Analyze the historical memory usage of the Serverless application to determine the basic memory boundary of the Serverless instance;
[0011] Step 2: Dynamically allocate a continuous memory block for the Serverless instance according to the basic memory boundary of the Serverless instance;
[0012] Step 3: During the life cycle of the Serverless instance, when the system state meets the preset conditions and the actual memory requirement exceeds the basic memory boundary, trigger the memory expansion mechanism;
[0013] Step 4: Through the Cinvoke mechanism, transfer the isolation domain in which the Serverless application runs to the Serverless runtime;
[0014] Step 5: The Serverless runtime realizes vertical memory expansion by increasing the number of memory blocks of a single Serverless instance;
[0015] Step 6: Use the LibOS memory management mechanism to initialize the new memory block and register it in the LibOS memory management to ensure the correct use and protection of memory.
[0016] Specifically, Step 2 includes: The Serverless application calls the memory dynamic allocation interface malloc provided by LibOS, and the malloc interface initiates a system call for memory allocation, attempting to allocate the required memory for the Serverless application in the existing memory pool.
[0017] Specifically, Step 3 includes: If the memory managed by LibOS is insufficient, the system triggers a preset "memory anchor" in the LibOS memory management system and enters the Memory notifier module. Memory notifier uses the Cinvoke mechanism provided by the CHERI architecture to notify the Serverless runtime that memory expansion is required.
[0018] Specifically, Step 5 includes:
[0019] Step 51, once the Serverless runtime receives the memory expansion requirement, its memory management module memmanager allocates an additional new memory segment for the CHERI isolation domain through the host-side interface;
[0020] Step 52, the Serverless runtime completes the Capability reconstruction of the CHERI isolation domain and reconfigures the boundaries and permissions of the linear memory area used by the isolation domain;
[0021] Step 53, the Serverless runtime returns from the processing function of the Cinvoke interface to the CHERI isolation domain, and LibOS obtains access rights to the additional memory area;
[0022] Step 54, Memory register registers the newly added memory after expansion into the system and brings it into the management scope of the memory module for the system to track and manage these additional memory resources;
[0023] Step 55, after successfully completing memory expansion, the previous failed memory allocation system call will reattempt to allocate memory and provide it for the Serverless application to use.
[0024] Specifically, before memory expansion in Step 3: Load LibOS into the virtual memory space, divide the LibOS memory area, and rearrange the LibOS memory area; the memory expansion mechanism is: allocate additional memory and merge it, and set new memory boundaries.
[0025] Specifically, loading LibOS into the virtual memory space includes: when starting an application instance in the Serverless runtime, loading LibOS into the virtual memory space of the Serverless runtime through memory mapping or loading instructions to establish the interaction between the Serverless runtime and LibOS.
[0026] Specifically, partitioning the LibOS memory area includes: determining the partitioning method and area size of the virtual memory according to application requirements and system resource conditions, and performing memory management by LibOS.
[0027] Specifically, rearranging the LibOS memory area includes: according to the requirements of the segment-based memory protection mechanism of the CHERI architecture, rearranging and allocating the memory area of LibOS to ensure that the newly allocated memory is continuous and conflict-free with the old memory.
[0028] Specifically, additionally allocating and merging memory includes: by calling the memory allocation interface provided on the host side, additionally allocating a memory space with the same permissions and continuous addresses as the LibOS heap memory area, and using the "memory merging" mechanism to merge the newly added memory block with the original LibOS heap memory to form a continuous virtual address space; the setting of the new memory boundary includes: using the function interface provided by the CHERI architecture to set the boundary of the memory area protected by Capability to the new memory boundary to ensure that the new memory area is correctly included within the protection scope.
[0029] Specifically, the registration mechanism of the LibOS memory in step 5 is set as follows: creating an independent memory area that does not participate in regular memory allocation; calculating and setting the space size of the reserved memory management structure; initializing the metadata within the range of the "basic memory boundary"; when increasing the memory capacity is required, initializing the metadata structure of the newly added memory area.
[0030] The beneficial effects of the present invention are as follows:
[0031] 1. Good compatibility: The present invention expands the memory through a software-hardware cooperation method without the need to modify the Serverless application, having good compatibility.
[0032] 2. Performance advantage: Vertical expansion avoids the cold start problem and maintains the performance of the application.
[0033] 3. High security: The present invention utilizes the segment-based memory protection mechanism of the CHERI architecture to ensure the isolation between different Serverless applications.
[0034] 4. Strong scalability: The memory vertical expansion method of the present invention can be dynamically adjusted according to actual needs, having good scalability.
[0035] 5. High resource utilization rate: By precisely allocating and releasing memory resources, the present invention improves the resource utilization rate of the server. Description of the Drawings
[0036] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.
[0037] Figure 1 It is a schematic flowchart of memory expansion allocation in the memory vertical expansion method of the present invention;
[0038] Figure 2 It is a schematic diagram of the memory expansion mechanism of Serverless runtime in the memory vertical expansion method of the present invention;
[0039] Figure 3 It is a schematic diagram of the LibOS memory registration mechanism in the memory vertical expansion method of the present invention. Detailed Embodiments
[0040] In order to make the technical problems, technical solutions and beneficial effects to be solved by the present invention more clearly understood, the following further details the present invention in conjunction with the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.
[0041] Under the CHERI architecture, Serverless runtime faces a challenge: how to flexibly and efficiently respond to load changes while avoiding resource waste. To solve this problem, the present invention proposes an application-agnostic memory vertical expansion method, which is a memory management method for Serverless runtime in the CHERI architecture. The method of the present invention utilizes the characteristics of the CHERI architecture to achieve the performance advantage of memory vertical expansion while maintaining the isolation of Serverless applications. The reason for "agnostic" is that the expansion process of this application is automatically triggered when the expansion condition (memory shortage) is met, without any modification to the user's Serverless application. The user does not know and does not need to pay attention to the occurrence of memory shortage, memory expansion and other situations.
[0042] The method of the present invention is specifically designed to meet the requirements of the segmented memory protection mechanism, including a complete set of processes, such as: how to trigger memory expansion, how to perform memory expansion and Capability reconfiguration by the Serverless runtime with the help of the CHERI mechanism through a communication mechanism, and how to use the memory rearrangement technology to move the LibOS heap memory to a new location. This process is designed very cleverly. When the system detects that the memory is insufficient to support allocation, it will automatically trigger memory expansion. Then, the system will notify the Serverless runtime that memory expansion is required through an efficient communication mechanism. The Serverless runtime will utilize the characteristics of the CHERI architecture to perform memory expansion and reconfiguration.
[0043] The method of the present invention constructs a protected continuous memory isolation domain based on Capability, called Capability Virtual Machine (CVM). On this isolation domain, the library operating system (LibOS) is run as the operating environment for Serverless applications. LibOS reuses some code of the Linux operating system, but is more concise and efficient to meet the high-performance requirements of the Serverless scenario.
[0044] Specifically, the present invention combines the memory expansion allocation process for the CHERI architecture, the memory expansion mechanism of the Serverless runtime, and the LibOS memory registration method to achieve dynamic memory expansion without affecting the existing system.
[0045] The memory expansion allocation process is a key part of the present invention, as Figure 1 shown, the detailed steps are as follows:
[0046] 1. The Serverless application calls the memory dynamic allocation interface provided by LibOS: When the Serverless application needs more memory, it will call the dynamic memory allocation interface provided by LibOS, such as malloc. This interface allows the application to request a certain amount of memory.
[0047] 2. Memory shortage triggers a warning: If the memory managed by LibOS is insufficient to meet the normal memory allocation request, the system will trigger the preset "memory anchor point" in LibOS and enter the memory expansion processing flow. The memory notifier will send a memory expansion application to the Serverless runtime.
[0048] 3. Use the Cinvoke mechanism of the CHERI architecture to notify the Serverless runtime: When memory shortage is detected, the memory notifier will use the Cinvoke mechanism provided by the CHERI architecture to notify the Serverless runtime. Cinvoke is a secure and efficient invocation mechanism that ensures secure communication between different components.
[0049] 4. The Serverless runtime receives the scaling-up requirement: Once the Serverless runtime receives the memory scaling-up requirement, its memory management module (mem manager) will be responsible for allocating an additional new memory segment for the CHERI isolation domain. This process involves interacting with the interface on the host side to ensure the correct allocation of the new memory.
[0050] 5. Capability reconstruction: Due to the segmented memory protection mechanism of the CHERI architecture, after the memory of the isolation domain is scaled up, the Capability of the isolation domain also needs to be reconstructed. This is to ensure that the new memory area has the correct access permissions and security configurations. The Capability management module (cap manager) will be responsible for reconfiguring these permissions and boundaries.
[0051] 6. Return to the CHERI isolation domain and register the new memory: After the above operations are completed, the Serverless runtime will return to the CHERI isolation domain through the handler function of the Cinvoke interface. At this time, LibOS has obtained the access permissions to the additional memory area and will register these new memory areas in the system and bring them under the management scope of the memory module.
[0052] 7. Memory registration: The memory register will register the newly added memory area after scaling up in the system, so that the system can uniformly manage and schedule these memory resources.
[0053] 8. Retry memory allocation: Once the vertical memory scaling up of the CHERI isolation domain is completed, the memory allocation system call that failed due to memory shortage before will retry memory allocation. This time, since the scaling up has been completed, the Serverless application will obtain the required memory and can continue its operations.
[0054] At this point, the vertical memory scaling up and allocation have been completed. The Serverless runtime has allocated an additional memory space for the application instance, ensured the continuity of the virtual memory addresses under the CHERI architecture, and completed the configuration of memory permissions to support the memory allocation requests of the Serverless application.
[0055] Generally speaking, this process is a collaborative working process, involving Serverless applications, LibOS, Serverless runtimes, and the security features of the CHERI architecture. Through such a process, it can ensure that memory expansion is carried out safely and efficiently in the Serverless environment, meet the growing resource requirements, and maintain the stability and security of the system.
[0056] The mechanism for memory expansion in Serverless runtimes is to meet the memory requirements of Serverless applications during operation. As Figure 2 shown, specifically, this mechanism includes the following key elements:
[0057] 1. Load LibOS into the virtual memory space: When a Serverless runtime starts an application instance, it loads LibOS into its own virtual memory space. In this way, LibOS can serve as the operating environment for this application instance and provide the required services.
[0058] 2. Divide the LibOS memory area: LibOS divides the loaded virtual memory space into different parts to support different functions. Among them, there is a part that is the LibOS heap memory, mainly used for dynamic memory allocation. This part of the memory is the main target area we focus on during expansion.
[0059] 3. Rearrange the LibOS memory area: The Serverless runtime rearranges part of the LibOS heap memory to the end of the LibOS memory space to support expansion operations on this area. This step is because under the CHERI architecture, the LibOS heap memory is located in the middle of a continuous memory area and cannot be expanded while ensuring address continuity.
[0060] 4. Allocate additional memory and merge: The Serverless runtime allocates additional memory with the same permissions and continuous addresses as the LibOS heap memory area through the memory allocation interface. This newly allocated memory is merged with the original LibOS heap memory into the same virtual address. The purpose of doing this is to ensure that the new and old memory areas are logically consistent for subsequent management and use.
[0061] 5. Set the new memory boundary: Finally, the Serverless runtime sets the boundary of the Capability-protected memory area to the new memory boundary through the CHERI function interface. This step is to ensure that the newly allocated memory area can be properly protected and managed to meet the requirements of security and performance.
[0062] Through the above steps, the Serverless runtime has completed the vertical expansion of memory, meeting the application's requirements while ensuring security.
[0063] Generally speaking, this mechanism is a complex process involving the coordinated work of multiple components and steps. Through such a mechanism, the Serverless runtime can dynamically expand its memory capacity to meet the growing application requirements while maintaining the stability and security of the system.
[0064] Through the above memory expansion mechanism, we have successfully solved the problem of difficult memory expansion in the LibOS heap memory area. Under the CHERI mechanism, the security protection of continuous memory areas is crucial. The LibOS memory registration mechanism enables the newly added memory areas to be correctly incorporated into the management of LibOS and ensures their security and continuity.
[0065] The LibOS memory registration mechanism is to ensure the dynamic management of memory, enabling the Serverless runtime to expand and contract memory according to requirements. As Figure 3 shown, this mechanism includes the following:
[0066] 1. Reserve management space: LibOS deliberately reserves a continuous space in its memory space that does not participate in daily memory allocation. This part of the space is mainly used for memory management, recording metadata information about available memory. These metadata are records of memory usage, allocation status, and other relevant information, which are very important for the system.
[0067] 2. Pass boundary information: When the Serverless runtime starts an instance, it passes two important boundary information to LibOS. One is the "basic memory boundary", which is the memory operation boundary of the system under low load and without the need for expansion. This boundary is usually provided by the cloud service provider as the basic configuration for system operation. The other is the "maximum memory boundary", which is the maximum memory operation boundary that can be reached through expansion and is usually specified by the user according to requirements.
[0068] 3. Initialize metadata: LibOS determines the size of the space required for the reserved memory management structure based on the "maximum memory boundary". However, when the instance starts, it only initializes the metadata of the part of the memory corresponding to the "basic memory boundary". The purpose of doing this is to save resources and only initialize the memory that is currently needed.
[0069] 4. Registration during memory expansion: When memory expansion is required, LibOS is responsible for initializing the metadata structure of the newly added memory and adding it to the memory management structure. In this way, the newly added memory is successfully registered in LibOS's memory management and can be used by the Serverless runtime at any time.
[0070] Through this mechanism, we not only solve the problem of the non-expandable LibOS memory management structure but also achieve the registration of newly added memory in Serverless application instances during memory expansion. In this way, the newly added memory area can be brought under the management scope of LibOS, ensuring its security and continuity.
[0071] Since the CHERI RISC-V hardware has not been released yet, the present invention provides an implementation method in a RISC-V simulation platform environment based on CHERI-QEMU. This means that we use simulation technology to simulate the RISC-V hardware environment for development and testing. To build this simulation platform, we selected specific underlying physical machines and operating systems. Specifically, we used a Core(TM) i7-10700 CPU @ 2.90GHz as the processor of the simulation platform to ensure its powerful performance to support the simulation environment. For the operating system, we chose Ubuntu 22.04.1, which is a popular open-source operating system that provides a good running environment for the simulation platform. To implement the present invention, we developed based on the Linux kernel 6.2.0-33-generic and CHERI-QEMU 5.2.0. These tools and software provide the necessary support for our simulation platform. It is worth mentioning that although we mainly developed based on these two versions, the implementation of the present invention is also applicable to other versions of QEMU and Linux kernels. The simulated RISC-V platform environment is equipped with some necessary devices and software. Specifically, it has a single-core CPU and 4GB of memory to ensure basic computing and storage requirements. In addition, it also has a virtio-blk device, which is a virtual block device that provides storage functions for the simulation platform. Most importantly, this simulation platform runs the CheriBSD 14.0 operating system, which is a BSD operating system based on the CHERI architecture and provides operating system support for our simulation.
[0072] On the CHERI RISC-V platform, the Serverless runtime is deployed as a process and starts and runs Serverless application instances based on LibOS. This means that when a Serverless application needs to run, it can leverage the resources and capabilities provided by LibOS. When an application instance requires more memory, it requests it through LibOS's dynamic memory allocation interface. If the requested memory exceeds the current memory limit, LibOS triggers a memory expansion mechanism. This mechanism involves multiple steps, ultimately handing over the request to the Serverless runtime through Cinvoke. The Serverless runtime communicates with the host interface to allocate additional memory and reconfigure capabilities. This means it obtains additional memory resources from the host and configures them according to the requirements of the CHERI architecture. LibOS manages the newly freed memory and registers it with the system. This allows the application to process subsequent memory allocation requests, and returns the newly allocated memory to the application.
[0073] The entire memory scaling process is completely transparent to the applications in the Serverless instance. This means that the application does not need to be aware of the specific details of the scaling process and can continue to operate normally and utilize the newly allocated memory resources. Furthermore, the Capability configuration is completed during the scaling process, ensuring memory security and isolation within the CHERI architecture.
[0074] In summary, this invention provides a method for vertical memory expansion that is applicable to the segmented memory protection mechanism. This method is specifically designed to meet the new isolation, compatibility, and performance requirements of serverless applications. The core of this method is that when the memory requirements of a serverless application instance exceed the currently allocated limits, the memory expansion mechanism in LibOS is triggered. This mechanism first checks whether there is sufficient free memory available for allocation. If so, LibOS allocates this free memory to the application instance and performs the necessary configuration and management to ensure security and isolation. This method allows serverless applications to achieve dynamic memory expansion without sacrificing isolation, compatibility, or performance. This design provides greater flexibility and scalability, enabling applications to better respond to changing memory requirements.
[0075] The beneficial effects of the present invention are:
[0076] (1) It can enable the Serverless runtime under the CHERI architecture to more flexibly respond to load changes, ensuring the normal operation of applications whether under high load or low load.
[0077] (2) It can minimize resource waste. By timely allocating or releasing memory for application instances, it can ensure the full utilization of resources and avoid unnecessary waste.
[0078] (3) It fully utilizes the advantages of the CHERI architecture, combines an efficient memory expansion mechanism and the LibOS memory registration method, and realizes the dynamic expansion of memory while meeting performance and security requirements.
[0079] (4) It deeply optimizes the memory allocation link through the cooperation of software and hardware, avoids modifying the Serverless application program, and achieves application transparency.
[0080] (5) It solves the difficulties of traditional Serverless runtime in memory expansion, including maintaining continuous memory, identifying and registering newly added memory, and simplifying memory management.
[0081] The above are only the preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent replacements, and improvements made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.
Claims
1. A method for vertical memory expansion without awareness of applications, characterized in that It includes the following steps: Step 1: Analyze the historical memory usage of the Serverless application to determine the basic memory boundary of the Serverless instance; Step 2: Dynamically allocate continuous memory blocks for the Serverless instance according to the basic memory boundary of the Serverless instance; Step 3: During the life cycle of the Serverless instance, when the system state meets the preset conditions and the actual memory requirement exceeds the basic memory boundary, trigger the memory expansion mechanism; Step 4: Through the Cinvoke mechanism, transfer the isolation domain where the Serverless application runs to the Serverless runtime; Step 5: The Serverless runtime realizes vertical memory expansion by increasing the number of memory blocks of a single Serverless instance; Step 6: Use the LibOS memory management mechanism to initialize the new memory blocks and register them in the LibOS memory management to ensure the correct use and protection of memory.
2. The method for vertical memory expansion without awareness of applications according to claim 1, wherein The said Step 2 includes: The Serverless application calls the memory dynamic allocation interface malloc provided by LibOS, and the malloc interface initiates a system call for memory allocation, attempting to allocate the required memory for the Serverless application in the existing memory pool.
3. The method for vertically expanding memory without awareness of applications as claimed in claim 1, wherein The said Step 3 includes: If the memory managed by LibOS is insufficient, the system triggers the preset "memory anchor" in the LibOS memory management system, enters the Memory notifier module, and the Memory notifier uses the Cinvoke mechanism provided by the CHERI architecture to notify the Serverless runtime that memory expansion is required.
4. The method for vertically expanding memory without awareness of applications as claimed in claim 1, wherein The said Step 5 includes: Step 51, once the Serverless runtime receives the memory expansion requirement, its memory management module memmanager allocates an additional new memory segment for the CHERI isolation domain through the interface on the host side; Step 52, the Serverless runtime completes the Capability reconstruction of the CHERI isolation domain, and reconfigures the boundaries and permissions of the linear memory area used by the isolation domain; Step 53, the Serverless runtime returns from the processing function of the Cinvoke interface to the CHERI isolation domain, and LibOS obtains the access permission to the additional memory area; Step 54, Memory register registers the newly added memory after expansion into the system and brings it into the management scope of the memory module for the system to track and manage these additional memory resources; Step 55, after successfully completing the memory expansion, the previous failed memory allocation system call will reattempt to allocate memory and provide it for the Serverless application to use.
5. The method for vertically expanding the memory without perception as described in claim 1, characterized in that, Before the memory expansion in the said Step 3, execute: Load LibOS into the virtual memory space, divide the LibOS memory area, and rearrange the LibOS memory area; The mechanism of memory expansion is: Allocate additional memory and merge it, and set new memory boundaries.
6. The application-agnostic memory vertical expansion method according to claim 5, characterized in that Loading the LibOS into the virtual memory space includes: when starting an application instance at the Serverless runtime, loading the LibOS into the virtual memory space of the Serverless runtime through memory mapping or loading instructions to establish the interaction between the Serverless runtime and the LibOS.
7. The method for vertical memory expansion without awareness of applications according to claim 5, characterized in that, Partitioning the LibOS memory area includes: determining the partitioning method and area size of the virtual memory according to the application requirements and system resource conditions, and performing memory management by the LibOS.
8. The method for vertically expanding memory without awareness of applications according to claim 5, wherein Rearranging the LibOS memory area includes: rearranging and allocating the memory area of the LibOS according to the requirements of the segment-based memory protection mechanism of the CHERI architecture to ensure that the newly allocated memory is continuous and conflict-free with the old memory.
9. The application-agnostic memory vertical expansion method according to claim 5, characterized in that Extra allocating and merging memory includes: by calling the memory allocation interface provided by the host side, extra allocating a memory space with the same permissions and continuous addresses as the LibOS heap memory area, and using the "memory merging" mechanism to merge the newly added memory block with the original LibOS heap memory to form a continuous virtual address space; setting the new memory boundary includes: using the function interface provided by the CHERI architecture to set the boundary of the memory area protected by Capability to the new memory boundary to ensure that the new memory area is correctly included in the protection scope.
10. The method for vertically expanding memory without awareness of applications as claimed in claim 1, wherein The registration mechanism of the LibOS memory in step 5 is set as follows: creating an independent memory area that does not participate in regular memory allocation; calculating and setting the space size of the reserved memory management structure; initializing the metadata corresponding to the "basic memory boundary" range. When increasing the memory capacity is needed, initialize the metadata structure for the newly added memory area.