Runtime virtual machine system, and system running method and apparatus

Abstract

A runtime virtual machine system. The system comprises: a user-mode application program (101); an asynchronous IO model (102), which is used for sharing an IO request memory queue between the user-mode application program (101) and a kernel mode; and a dynamic runtime library (103), which can be loaded when the user-mode application program (101) is started, wherein the dynamic runtime library (103) is used for generating, after being loaded, a runtime virtual environment for replacing a runtime environment of the user-mode application program (101), the dynamic runtime library (103) comprises an IO operation library function hook (1031) and a monitoring thread function (1032), the IO operation library function hook (1031) is constructed on the basis of a native library function of the user-mode application program (101), and the IO operation library function is used for adapting an application program interface of the native library function to the asynchronous IO model (102) in the runtime virtual environment, such that an IO operation of an operating system where the user-mode application program (101) is located is transformed to be processed by the asynchronous IO model (102).

Description

Runtime virtual machine system, system operation method and device

[0001] This patent application claims priority to the Chinese patent application filed on July 28, 2023, with application number 202310943023.5 and invention name “Runtime virtual machine system, system operation method and device”, the full text of which is incorporated by reference into this application. Technical Field

[0002] The present disclosure relates to the field of computer technology, and in particular to a runtime virtual machine system, a system operation method and apparatus, an electronic device, and a computer-readable medium. Background Art

[0003] Existing runtime virtual machine technology is generally developed based on the C runtime library. Various operating systems provide system call encapsulation through the C runtime library. Applications executed in various runtime virtual machine environments actually need to call the host operating system's system calls to implement low-level IO operations. However, compared with user-mode code, the cost of executing system calls is extremely high.

[0004] Summary of the Invention

[0005] The embodiments of the present disclosure provide a thread virtualization method and apparatus, a runtime virtual machine system, an electronic device, and a computer-readable medium.

[0006] In the first aspect, an embodiment of the present disclosure provides a runtime virtual machine system, which includes: a user-state application; an asynchronous IO model for sharing an IO request memory queue between the user-state application and the kernel state to realize asynchronous driving of physical devices; a dynamic runtime library that can be loaded when the user-state application is started, and the dynamic runtime library is used to generate a runtime virtual environment that replaces the runtime environment of the user-state application after being loaded; wherein the dynamic runtime library includes an IO operation library function hook and a monitoring thread function; the IO operation library function hook is constructed based on the native library function of the user-state application, and the IO operation library function is used to adapt the application interface and asynchronous IO model of the native library function in the runtime virtual environment, and convert the IO operation of the operating system where the user-state application is located to be processed by the asynchronous IO model; the monitoring thread function is used to monitor whether the IO operation of the asynchronous IO model is completed in the runtime virtual environment, and when the IO operation is completed, wake up the task that is in a waiting state due to the IO operation.

[0007] In some embodiments, the above-mentioned IO operation library function hook includes: a file descriptor management hook function, a file descriptor read and write hook function, and a POLL status hook function; the file descriptor management hook function is used to create a file descriptor in a runtime virtual environment, put the file descriptor into the file descriptor table, and register the file descriptor to the asynchronous IO model; the file descriptor management hook function is also used to deregister the file descriptor from the asynchronous IO model in the runtime virtual environment when the file descriptor is closed; the file descriptor read and write hook function is used to receive a read request or a write request for the file descriptor in the runtime virtual environment, and put the read request or the write request into the submission queue of the asynchronous IO model; the POLL status hook function is used to receive a POLL wait request or a POLL wake-up request in the runtime virtual environment, and put the POLL wait request or the POLL wake-up request into the submission queue of the asynchronous IO model.

[0008] In some embodiments, the above-mentioned dynamic runtime library uses coroutines to simulate threads implemented in native library functions, and the IO operation library function hooks include: file IO hook functions and file IO callback functions, network IO hook functions and network IO callback functions; the file IO hook function is a function constructed using a hook (HOOK) mechanism and is related to the file IO library function in the native library function; the network IO hook function is a function constructed using a HOOK mechanism and is related to the network IO library function in the native library function; the file IO hook function and the network IO hook function are used to determine whether the operation subject is a coroutine when suspending or waiting for the IO operation to be completed in the runtime virtual environment. If it is a coroutine, the coroutine is suspending the coroutine using a coroutine switching or suspension mechanism; the file IO callback function is used to change the IO-related operations in the file IO hook function to be synchronized with the asynchronous IO model in the runtime virtual environment; the network IO callback function is used to change the IO-related operations in the network IO hook function to be synchronized with the asynchronous IO model in the runtime virtual environment.

[0009] In some embodiments, the above-mentioned dynamic runtime library also includes: a thread scheduling library function hook. The thread scheduling library function hook is a function related to the thread creation, recycling and suspension library functions in the native library function constructed using the HOOK mechanism. The thread creation, recycling and suspension library functions are functions in the native runtime library of the application that can create, recycle and suspend threads. The thread scheduling library function hook is used to replace the creation and recycling of threads with the creation and recycling of coroutines in the runtime virtual environment, and after the application is running, generate a coroutine scheduling thread to schedule at least one coroutine through the coroutine scheduling thread.

[0010] In some embodiments, the above-mentioned dynamic runtime library also includes: a memory management library function hook, which is a function related to memory management in the native library function constructed using the HOOK mechanism. The memory management library function hook is used to enable a thread to start one or more memory allocation areas in the runtime virtual environment. The coroutines belonging to the current coroutine scheduling thread are grouped according to the memory allocation area, and the coroutines belonging to the same memory allocation area share the same coroutine scheduling thread cache.

[0011] In some embodiments, after the user-mode application is started and in the runtime virtual environment, the monitoring thread function creates a monitoring thread for each context in the asynchronous IO model. The monitoring thread is used to poll the completion queue of the asynchronous IO model. When a new ready task is received in the completion queue, the coroutine in the waiting queue corresponding to the IO operation library function hook is awakened.

[0012] In a second aspect, an embodiment of the present disclosure provides a system operation method, the method comprising: loading a library file of an asynchronous IO model, the asynchronous IO model being used to enable a user-mode application to share an IO request memory queue with a kernel-mode application to implement asynchronous driving of a physical device; when starting the user-mode application to run, loading a dynamic runtime library to generate a runtime virtualization environment, the runtime virtualization environment being an environment that replaces the runtime environment of the user-mode application; in response to detecting call information from the user-mode application to a native library function of the user-mode application, converting an IO operation of the operating system where the user-mode application is located to be processed by the asynchronous IO model through an IO operation library function;

[0013] In the runtime virtualization environment, the IO operation of the asynchronous IO model is monitored by monitoring the thread function to see whether it is completed, and when the IO operation is completed, the task that is in the waiting state due to the IO operation is awakened by the monitoring thread function.

[0014] In a third aspect, an embodiment of the present disclosure provides a system operation device, which includes: a file loading unit, configured to load a library file of an asynchronous IO model, wherein the asynchronous IO model is used to share an IO request memory queue between user-mode applications and kernel-mode to realize asynchronous driving of physical devices; a library loading unit, configured to load a dynamic runtime library and generate a runtime virtualization environment when starting the user-mode application runtime, wherein the runtime virtualization environment is an environment that replaces the runtime environment of the user-mode application; a conversion unit, configured to convert the IO operation of the operating system where the user-mode application is located into processing by the asynchronous IO model through the IO operation library function when the user-mode application detects the calling information of the native library function of the user-mode application in the runtime virtual environment; a wake-up unit, configured to monitor whether the IO operation of the asynchronous IO model is completed through the monitoring thread function in the runtime virtual environment, and when the IO operation is completed, wake up the task that is in a waiting state due to the IO operation through the monitoring thread function.

[0015] In a fourth aspect, an embodiment of the present disclosure provides an electronic device comprising: one or more processors; a storage device on which one or more programs are stored; when the one or more programs are executed by one or more processors, the one or more processors implement the method described in any embodiment of the second aspect.

[0016] In a fifth aspect, an embodiment of the present disclosure provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the method described in any embodiment of the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Other features, objects and advantages of the present disclosure will become more apparent from a reading of the detailed description of non-limiting embodiments made with reference to the following drawings:

[0018] FIG1 is a schematic structural diagram of an embodiment of a runtime virtual machine system according to the present disclosure;

[0019] FIG2 is a schematic structural diagram of another embodiment of a runtime virtual machine system according to the present disclosure;

[0020] FIG3 is a flow chart of an embodiment of a system operation method according to the present disclosure;

[0021] FIG4 is a schematic structural diagram of an embodiment of a system operation device according to the present disclosure;

[0022] FIG5 is a schematic structural diagram of an electronic device suitable for implementing the embodiments of the present disclosure. DETAILED DESCRIPTION

[0023] The present disclosure will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are intended only to illustrate the relevant invention and are not intended to limit the invention. It should also be noted that, for ease of description, only portions relevant to the relevant invention are shown in the accompanying drawings.

[0024] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments in the present disclosure can be combined with each other. The present disclosure will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0025] Runtime virtual machine systems are often used to provide cross-platform support or virtualized runtime environments, and dynamic library injection is a technical solution that can be used to implement runtime virtual machines. A dynamic library is injected into an application, and this dynamic library's function hooks override functions in the original application and functions in dynamic libraries linked to the original application.

[0026] Applications running in various runtime virtual machine environments must invoke system calls from the host operating system. However, executing system calls is extremely costly. This is because: first, falling into and returning from a system call requires a switch from user mode to kernel mode, and then a switch from kernel mode to user mode. Second, the user mode virtual address space is isolated from the kernel mode address space, preventing direct memory access between user mode and kernel mode, requiring a memory copy. Given the high cost of system calls, several high-performance pure user mode programming models have been proposed. These models minimize system calls (allowing applications to run in user mode for the majority of the time, without any user / kernel mode switching) to improve application performance and achieve higher I / O throughput.

[0027] Given that some existing pure user-mode programming models lack a complete network protocol stack and file system ecosystem, and some do not provide complete support for application interfaces, code modification is required when applications are connected, which is complex to implement, difficult to operate, and has high labor costs.

[0028] In order to better understand traditional technology, some terms are introduced below:

[0029] A shared library, also known as a dynamic link library, is a way to implement shared functions or objects in an operating system. Compiled functions are stored in a dynamic library. Applications can dynamically load these library files and reference corresponding functions by name. The same dynamic library can be loaded by different applications.

[0030] C runtime library: A general term for a class of dynamically linked libraries that encapsulates system calls and various operating system management interfaces, providing a C-based programming interface for runtime interaction between applications and the operating system. Applications can be built directly on the C runtime library, or run on a runtime virtual machine built on the C runtime library (such as the Java Virtual Machine (JVM)). In Linux-like systems, different distributions provide their own C runtime libraries (generally following the POSIX (Portable Operating System Interface) protocol or some extension based on POSIX); for example, the C runtime library in the GNU distribution is called "glibc," while the C runtime library in the Android distribution is called "bionic." In Windows systems, the C runtime library is called the CRT library.

[0031] Runtime virtual machine (RVM): A general term for programs and libraries that provide a development interface and runtime environment for other applications. These programs are typically developed based on the C runtime library and are designed to provide a cross-platform program execution environment. Compared to a virtual machine (VM), a RVM does not fully emulate a virtual host; it simply provides a runtime environment, making it more lightweight.

[0032] Dynamic library injection: Reverse engineering a third-party application to cause it to execute injected code is called "code injection," and dynamic library injection is one method of achieving code injection. Dynamic library injection involves loading a dynamic library into an application and injecting code from the library into the target application, causing it to execute that code or dynamically replacing the original code with the injected code.

[0033] Kernel State and User State: To ensure system security, modern CPUs typically have several different instruction levels. At a high execution level, code can execute privileged instructions and access arbitrary physical addresses; this level corresponds to the operating system's kernel state. At a low execution level, code's control is restricted, limiting its scope to activities permitted by the corresponding level; this level corresponds to user state. When a user-state program needs to execute functionality provided by the operating system kernel, it can execute a corresponding system call, switching from user state to kernel state and running code at a higher execution level in kernel state.

[0034] User-mode drivers: Device drivers typically run in kernel space. However, with the continuous advancement of hardware and software technologies, the drawbacks of kernel-mode drivers have gradually become apparent when attempting to provide high-concurrency server connections. These include the significant overhead of system calls (every device access by an application must go through a system call), the extremely high requirements for driver stability (kernel-mode errors can directly cause system crashes), the steep learning curve for developers, and the instability of development interfaces (changes to the kernel driver interface during kernel upgrades require the driver to be re-adapted to the new kernel version). Consequently, hardware companies such as Intel, Texas Instruments, and Freescale began researching this issue and developing user-mode driver solutions for their hardware.

[0035] DPDK and SPDK: DPDK (Data Plane Development Kit) is a user-mode network card driver solution. DPDK defines an operating environment that defines a kernel thread for each CPU core. In order to maximize network throughput, each kernel thread is bound to its corresponding CPU core, and no other threads will run on the CPU core that has been bound to the core. Therefore, kernel threads will occupy CPU computing power. The more kernel threads are started, the higher the parallel throughput capability of the network device, but the more computing power is occupied. SPDK (Storage Performance Development Kit) is a user-mode storage device driver suite developed based on DPDK, which aims to provide high-performance driver solutions for its high-speed storage devices.

[0036] Io_uring technology: A new asynchronous input / output (I / O) model, io_uring addresses issues such as high system call and memory copy overhead, support for direct I / O only, and data size alignment restrictions. It leverages memory mapping to create a shared ring-shaped memory queue between user and kernel mode, reducing system calls and memory copies through shared memory communication. Ideally, it can achieve zero system call I / O access.

[0037] Coroutine: also known as "fiber thread" or "micro" thread, a computer component that generates non-preemptive multi-tasking subroutines. Coroutines are generally attached to a thread, allowing different subroutine entries to pause or start at the same location; simply put, a coroutine is a function that can be paused and started. Different coroutines can be regarded as different functions, which are called and executed by the host thread; during the execution process, the coroutine can return to the location where the host thread called the coroutine by actively giving up (that is, "yield"); and when the host thread calls the coroutine function again (that is, "resume"), the coroutine will continue to execute from the previous yield point.

[0038] Thread local storage (TLS): also known as thread local storage, is a solution to thread safety issues in specific scenarios. Simply put, it is a variable with a global scope to the process. When it has a thread local constraint, this variable can have different values ​​in different threads (i.e., thread local values). TLS is divided into two types and three cases according to the implementation method. The first type is a variable with a thread local constraint declared during coding, for example: static__thread int global_tls_value=0;

[0039] The variable declaration above represents a global integer variable with an initial value of 0. This variable is accessible by all threads in the program; however, changes to the variable's value by different threads are only visible to the thread itself. The location of this type of TLS variable in the program's data segment and its initial value are determined during compilation. Therefore, its relevant information and initial value are stored in the compiled target program, and its location in the thread-local context is locked when the program is loaded. Alternatively, when the program loads a dynamic library at runtime, if that dynamic library also contains TLS variables, the location of these TLS variables in the thread-local context must be dynamically determined when the dynamic library is loaded. In addition to TLS variables declared during coding, there is a second type of TLS variable: dynamically created TLS.

[0040] The runtime virtual machine system provided by the embodiments of the present disclosure includes: a user-state application; an asynchronous IO model for sharing an IO request memory queue between the user-state application and the kernel state to realize asynchronous driving of physical devices; a dynamic runtime library that can be loaded when the user-state application is started, and the dynamic runtime library is used to generate a runtime virtual environment that replaces the runtime environment of the user-state application after being loaded; wherein the dynamic runtime library includes an IO operation library function hook and a monitoring thread function; the IO operation library function hook is constructed based on the native library function of the user-state application, and the IO operation library function is used to adapt the application interface and asynchronous IO model of the native library function in the runtime virtual environment, and convert the IO operation of the operating system where the user-state application is located into processing by the asynchronous IO model; the monitoring thread function is used to monitor whether the IO operation of the asynchronous IO model is completed in the runtime virtual environment, and when the IO operation is completed, wake up the task that is in a waiting state due to the IO operation. Therefore, after the user-state application is started, the runtime dynamic library of the present invention is loaded into the memory of the user-state application to generate a runtime virtual environment. The runtime virtual environment can directly replace the runtime environment of the native runtime library of the user-state application, take over the IO operations of the operating system where the user-state application is located, and convert the IO operations into processing by the asynchronous IO model. By processing IO operations through the asynchronous IO model, the number of system calls is reduced and the IO performance is improved. Through dynamic injection technology, without making any modifications to the application, the user-state application has pure user-state IO capabilities, saving labor costs and improving the convenience of user-state application operations.

[0041] The present disclosure provides a runtime virtual machine system. FIG1 shows a schematic diagram of the structure of an embodiment of the runtime virtual machine system according to the present disclosure. The runtime virtual machine system 100 includes a user-mode application 101, an asynchronous I / O model 102, and a dynamic runtime library 103. The asynchronous I / O model 102 is used to enable the user-mode application 101 and the kernel mode to share an I / O request memory queue, thereby implementing asynchronous driving of physical devices.

[0042] The dynamic runtime library 103 is loaded into the memory of the user-state application 101 when the user-state application is started. After the dynamic runtime library is loaded, a runtime virtual environment is generated to replace the runtime environment of the user-state application. The dynamic runtime library 103 includes an IO operation library function hook 1031 and a monitoring thread function 1032. The IO operation library function hook 1031 is constructed based on the native library function of the user-state application. The IO operation library function 1031 is used to adapt the application interface of the native library function and the asynchronous IO model 102 in the runtime virtual environment, and convert the IO operation of the operating system where the user-state application is located into processing by the asynchronous IO model.

[0043] The monitoring thread function 1032 is used to monitor whether the IO operation of the asynchronous IO model 102 is completed in the runtime virtual environment, and wake up the task that is in a waiting state due to the IO operation when the IO operation is completed.

[0044] In this embodiment, user-mode application 101 is an application that runs in user mode. User mode provides a space for application execution. Generally, all applications can only run in user mode. The native library functions of a user-mode application are functions compiled into the user-mode application's native C runtime library. The native runtime library is a dynamic link library that the user application calls to implement its functions. Compared to the dynamic runtime library of the present disclosure, the application must make multiple calls to the host operating system's system calls, which are more expensive.

[0045] In this embodiment, the dynamic runtime library 103 is loaded when the user-mode application is running, and generates a runtime virtual environment that is different from the runtime environment of the user-mode application. The execution logic of the library function in the dynamic runtime library can directly replace the execution logic of the library function in the native runtime library, or, under some conditions, replace the execution logic of the library function in the native runtime library, and under other conditions, retain the execution logic of the library function in the native runtime library.

[0046] In this embodiment, when the operating system where the user-mode application is located has an IO operation, the library function of the dynamic runtime library 103 during runtime can directly convert the IO operation into processing by the asynchronous IO model.

[0047] In this embodiment, the asynchronous IO model 102 is a model implemented based on memory mapping technology. The asynchronous IO model can prevent the application from falling into any system call when allocating or releasing memory, thereby improving the efficiency of memory allocation or release.

[0048] In this embodiment, the asynchronous IO model 102 can adopt io_uring, and io_uring also adopts memory mapping technology to share IO cache between user mode and kernel mode. As the name implies, the memory cache of io_uring is a "ring queue", and the application can also realize data interaction with the device through the state of the memory cache in the circular queue. Unlike DPDK that directly drives physical devices, io_uring can access devices or files based on file handles (that is, it supports kernel protocol stacks and file systems). io_uring encapsulates all operations of accessing the kernel protocol stack and file system asynchronously inside the kernel. The IO operations initiated by the application through io_uring will not fall into system calls at all, and there is no need to perform memory copies between the kernel.

[0049] In this embodiment, the asynchronous I / O model includes a submission queue (SQ) and a completion queue (CQ). The submission queue is a circular queue stored in a continuous block of memory space, used to store data for executing I / O operations. The data is an index into the submission queue entry array (SQE), and the submission queue entry data is an item in the submission queue. The completion queue is a circular queue stored in a continuous block of memory space, used to store the results returned after the I / O operation is completed.

[0050] Optionally, the asynchronous IO model can also use DPDK or SPDK with a complete kernel protocol stack and file system. DPDK / SPDK is an asynchronous model that is fully implemented in user mode, but the file system and protocol stack ecosystem of the two are incomplete. Through code development for DPDK or SPDK, program developers can access devices or files based on file handles (that is, implement a system equivalent to the kernel protocol stack and kernel file system in user mode). The specific code development process will not be repeated here.

[0051] In this embodiment, the monitoring thread function can be a function that generates a monitoring thread in a runtime virtual environment. The monitoring thread generated by the monitoring thread function can monitor the execution of IO operations by the asynchronous IO model in real time. When the IO operation is completed, the task that is in a waiting state due to the IO operation is awakened to ensure the effective execution of the task.

[0052] The runtime virtual machine system provided by the embodiments of the present disclosure includes: a user-state application; an asynchronous IO model, which is used to share an IO request memory queue between the user-state application and the kernel state to realize asynchronous driving of physical devices; a dynamic runtime library that can be loaded when the user-state application is started, and the dynamic runtime library includes an IO operation library function hook and a monitoring thread function; the IO operation library function hook is constructed based on the native library function of the user-state application, and the IO operation library function is used to adapt the application program interface and the asynchronous IO model of the native library function in the runtime virtual environment, and convert the IO operation of the operating system where the user-state application is located into processing by the asynchronous IO model; the monitoring thread function is used to monitor whether the IO operation of the asynchronous IO model is completed in the runtime virtual environment, and when the IO operation is completed, wake up the task that is in a waiting state due to the IO operation. Therefore, after the user-state application is started, the runtime dynamic library disclosed in the present invention is loaded into the memory of the user-state application, and can directly replace the native runtime library of the user-state application, take over the IO operations of the operating system where the user-state application is located, and convert the IO operations into processing by the asynchronous IO model. By processing IO operations through the asynchronous IO model, the number of system calls is reduced and the IO performance is improved. Through dynamic injection technology, without making any modifications to the application, the user-state application has pure user-state IO capabilities, saving labor costs and improving the convenience of user-state application operations.

[0053] In some optional implementations of the present disclosure, the IO operation library function hooks include: a file descriptor management hook function, a file descriptor read and write hook function, and a polling (POLL) status hook function.

[0054] Among them, the above-mentioned file descriptor management hook function is used to create a file descriptor in the runtime virtual environment, put the file descriptor into the file descriptor table, and register the file descriptor in the asynchronous IO model; the file descriptor management hook function is also used to deregister the file descriptor from the asynchronous IO model when closing the file descriptor in the runtime virtual environment, and release the content corresponding to the file descriptor in the file descriptor table.

[0055] The above-mentioned file descriptor read and write hook functions are used to receive read requests or write requests for file descriptors in the runtime virtual environment, and put the read requests or write requests into the submission queue of the asynchronous IO model.

[0056] The above-mentioned POLL state hook function is used to receive a POLL wait request or a POLL wake-up request in a runtime virtual environment, and put the POLL wait request or the POLL wake-up request into the submission queue of the asynchronous IO model.

[0057] The IO operation library function hook provided in this embodiment includes: a file descriptor management hook function, a file descriptor read / write hook function, and a POLL status hook function. Compared with the file descriptor management function in the native library function, the file descriptor management hook function has the ability to communicate data with the asynchronous IO model and can register or unregister the file descriptor to the asynchronous IO model; compared with the file descriptor read / write function in the native library function, the file descriptor read / write hook function can put the read request and write request of the file descriptor into the submission queue of the asynchronous IO model, so that the reading and writing of the file descriptor are both in user mode, further reducing system calls and improving IO performance; compared with the POLL status function in the native library function, the POLL status hook function can put the POLL wait request or POLL wake-up request into the submission queue of the asynchronous IO model, further reducing system calls and improving IO performance.

[0058] In some optional implementations of the present disclosure, the dynamic runtime library uses coroutines to simulate threads implemented in native library functions, and the IO operation library function hooks include: file IO hook functions and file IO callback functions, network IO hook functions and network IO callback functions.

[0059] In this embodiment, the file IO hook function and the network IO hook function are used to determine whether the operation subject is a coroutine when suspending or waiting for the completion of an IO operation in a runtime virtual environment. If it is a coroutine, the coroutine is suspending by using a coroutine switching or suspension mechanism.

[0060] The aforementioned file IO hook function is constructed using the hook mechanism and is related to the file IO library functions in the native library. When the native library functions are functions of the C runtime library, the functions related to the file IO library functions in the native library include: lseek, read / write, readv / writev, etc. The file IO hook function determines whether the current context is in a thread state. If so, it calls the native system call or library function. If it is a coroutine, it uses the file IO hook function's own logic.

[0061] Network IO hook functions are built using the HOOK mechanism and are related to network IO library functions in native libraries. When the native library functions are C runtime library functions, the functions related to network IO library functions in native libraries include: socket / close, listen / accept, send / recv, sendto / recvfrom, sendmsg / recvmsg, read / write, readv / writev, poll / select / epoll_wait, etc. When a new socket file is created (by calling socket or accept), the network IO hook function adds the newly created socket file descriptor to the structure management file (UrFd) table and processes all network IO operations related to the socket file descriptor through the asynchronous IO model (such as processing the poll_wait operation through the asynchronous IO model).

[0062] For system native threads (including the main thread), there is no problem with blocking waiting and suspending the current thread. Therefore, in the network IO hook function, it is determined whether the current context is in the thread state when suspending or waking up. If it is a thread, the thread suspension or wake-up mechanism is adopted, that is, thread suspension or wake-up; if it is a coroutine, the coroutine suspension or wake-up mechanism is adopted, that is, the coroutine's yield / resume.

[0063] The network IO hook function is used to manage file descriptors and the POLL status corresponding to file descriptors through the UrFd structure when the coroutine calls library functions such as send / recv and attempts to enter blocking waiting. If the corresponding receive or send buffer is not ready, the current coroutine context is marked to enter IO waiting on this socket and yield is used.

[0064] Similarly, when a coroutine calls a library function like poll to wait for certain sockets to become ready, the network IO hook function checks the UrFd table to see if any of these sockets are already ready. If so, it returns immediately; if not, it marks all sockets monitored by this poll operation as being in the IO wait state for the current coroutine context and yields the state.

[0065] When the background epoll thread receives a batch of socket ready signals, it checks whether there is a coroutine context marking the IO wait state on these sockets. If so, it wakes up these coroutines in batches.

[0066] The dynamic runtime library has a hook function for generating a coroutine scheduling thread. After the coroutine scheduling thread is generated, each coroutine scheduling thread maintains a lock-free wakeup queue. Waking up a coroutine means putting the coroutine context of this coroutine into the wakeup queue of its scheduling thread.

[0067] In this embodiment, in this embodiment, the execution subject uses its own UrFd structure and UrFd table (also a lock-free hash table) to manage the opened file descriptors. The UrFd structure contains at least the following three fields: the first is the file descriptor (that is, the primary key of the UrFd table); the second is the poll status of the file; and the third is the lock-free waiting queue. The difference from the virtual machine system generated by the file IO hook function and the network IO hook function is that in the IO hook function of the virtual machine system, the library function will only be taken over in the coroutine context state; in the thread context state, it is still implemented by executing the system call. However, the core goal of this embodiment is to build a "pure user state" runtime environment, so even in the thread context state, it is necessary to use a pure user state method to implement it, that is, by converting the IO operation to be implemented by the asynchronous IO model, and using a pure user state solution as much as possible to improve the overall performance. In the UrFd structure disclosed in the present invention, the lock-free waiting queue is used to maintain the situation where multiple coroutines (or threads) are trapped in poll waiting or IO waiting on the same file descriptor.

[0068] In this embodiment, the file IO callback function is used to change the IO-related operations in the file IO hook function to synchronize with the asynchronous IO model in the runtime virtual environment; the file IO callback function can take over the file IO library function and connect to the asynchronous IO model to achieve the purpose of synchronization with the asynchronous IO model. Specifically, the file IO callback function includes: a first callback function related to file descriptor reading, the first callback function is used to submit the read request related to the file descriptor to the submission queue of the asynchronous IO model after receiving the read request related to the file descriptor, by putting the current coroutine context into the waiting queue of the corresponding file descriptor and using the yield (or thread suspension) method to give it up. When the asynchronous IO model is ready, the state of the file descriptor is set, and the coroutine (or thread) in the waiting queue of the file descriptor is stopped, wherein the waiting queue of the file descriptor is a lock-free queue structure that supports waiting with timeout / no timeout, and also supports coroutine swapping and thread suspension.

[0069] The file IO callback function also includes a second callback function related to file descriptor writes. Upon receiving a write request related to the file descriptor, the second callback function is configured to submit the write request to the asynchronous IO model's submission queue by placing the current coroutine context into the corresponding file descriptor's wait queue and yielding the context (or suspending the thread). Upon receiving a ready message from the asynchronous IO model, the second callback function sets the file descriptor's state and terminates the coroutine (or thread) in the file descriptor's wait queue.

[0070] The network IO callback function is used to change the IO-related operations in the network IO hook function to synchronize with the asynchronous IO model in the runtime virtual environment. The network IO callback function can take over the network IO library function and connect to the asynchronous IO model to achieve the purpose of synchronization with the asynchronous IO model.

[0071] In this embodiment, the network IO callback function includes: a second callback function related to file descriptor management (creation or closing), and a third callback function related to POLL waiting. The second callback function is started when a file descriptor is created or closed, creates a UrFd structure for the newly created file descriptor, puts it into the UrFd table, and registers the file descriptor with the asynchronous IO model; when the file descriptor is closed, the file descriptor is deregistered from the asynchronous IO model and the corresponding UrFd structure in the UrFd table is released.

[0072] If the poll state is not ready, the third callback function submits the poll state request to the asynchronous I / O model's submission queue, places the current coroutine context in the UrFd wait queue, and uses yield (or thread suspension) to release it. Waiting operations with timeouts are implemented using a lockless timeout queue.

[0073] The dynamic runtime library provided in this embodiment implements the coroutine simulation of file IO and network IO in native library functions through file IO hook functions and network IO hook functions, takes over the functions of the file IO hook function through the file IO callback function and realizes docking with the asynchronous IO model, and takes over the network IO hook function through the network IO callback function and realizes docking with the asynchronous IO model, thereby increasing the user state effect of the runtime environment of the runtime virtual machine system, reducing system calls, and improving IO performance.

[0074] In some optional implementations of this embodiment, as shown in Figure 2, the dynamic runtime library also includes: a thread scheduling library function hook. The thread scheduling library function hook is a function related to the thread creation, recycling and suspension library functions in the native library function constructed using the HOOK mechanism. The thread creation, recycling and suspension library functions are functions in the native runtime library of the application that can create, recycle and suspend threads. The thread scheduling library function hook is used to replace the creation and recycling of threads with the creation and recycling of coroutines in the runtime virtual environment, and generate a coroutine scheduling thread after the application is running to schedule at least one coroutine through the coroutine scheduling thread.

[0075] In this embodiment, a coroutine scheduling thread can be generated by loading a dynamic runtime library when starting a user-mode application.

[0076] Among them, the coroutine scheduling thread includes: a scheduler and a lock-free queue for placing at least one coroutine, and the specific steps of the coroutine scheduling thread scheduling at least one coroutine include: the scheduler obtains the coroutine in the ready state from the lock-free queue of at least one coroutine; synchronizes the coroutine context of the coroutine with the thread context in the thread control block; after the coroutine voluntarily gives up, the scheduler obtains the next coroutine in the ready state from the lock-free queue, and synchronizes the coroutine context of the next coroutine with the thread context in the thread control block; after the next coroutine voluntarily gives up, the scheduler continues to obtain coroutines from the lock-free queue and synchronize the thread control block until there is no coroutine in the lock-free queue.

[0077] In this embodiment, the thread control block (TCB) is a thread data structure within the native runtime library, known as a thread control block (TCB). It also serves as the thread context structure. DTV and specific array are the data structures within the TCB that store TLS data. DTV is used to store TLS variables defined during the coding phase. This data increments as the application loads new dynamic libraries, as these libraries may also contain TLS variables.

[0078] Specific: Dynamically created TLS (the library functions for creating and deleting TLS keys are pthread_key_create and pthread_key_delete, respectively; the library functions for reading and modifying TLS values ​​are pthread_getspecifix and pthread_setspecific, respectively). This type of TLS is maintained using a set of pointer arrays (specific arrays), so there is an upper limit on the number of dynamic TLS connections (Linux supports a maximum of 1024).

[0079] In this embodiment, the scheduler performs incremental synchronization of TLS data between the TCB and the coroutine context.

[0080] In the thread scheduling library function hook, the coroutine context structure is used to replace the thread descriptor, and the currently running thread or coroutine is marked by a global variable with a thread local constraint. The thread local storage information in the coroutine context structure is managed by the synchronization management module. The synchronization management module is used to synchronize the thread local storage of the coroutine when the coroutine scheduling thread schedules the coroutine.

[0081] The coroutine context structure (hereinafter referred to as COCTX structure) is a structure for placing the coroutine context (hereinafter referred to as COCTX), which is used to maintain the context of the coroutine. It is similar to the role of the thread descriptor (or thread handle). In order to provide compatibility with thread behavior, it is necessary to hook the library functions for creating threads and obtaining thread descriptors in the native runtime library and replace the thread descriptor with COCTX. Taking Linux as an example, its thread descriptor is called "TCB", and its implementation is a structure called "pthread". The calls to create threads and obtain thread descriptors in Linux are:

[0082] pthread_create: creates a thread and returns a thread descriptor. The value of this thread descriptor is the address of the TCB structure. In this embodiment, the hook for creating a thread function is replaced by a pointer to COCTX.

[0083] pthread_self: Get the descriptor of the current thread, also replaced by the COCTX pointer.

[0084] In this embodiment, a global TLS variable (a global variable with thread-local constraints) can be used to obtain the context of the current coroutine, which is declared as follows: extern__thread COCTX*_current_coctx;

[0085] In this embodiment, COCTX has the following four types:

[0086] Coroutine COCTX: corresponds to an actual coroutine;

[0087] Global COCTX: The main thread's _current_coctx will be set to global COCTX, which will be created when the runtime dynamic library is just loaded;

[0088] Scheduler COCTX: Each coroutine scheduling thread (that is, the thread that runs the coroutine) will have a default COCTX. If no coroutine is in the ready state or there is an intermediate state between two coroutines, the current thread's _current_coctx will be set to scheduler COCTX;

[0089] Single COCTX: When a system native thread is created, a virtual COCTX is created for it.

[0090] As shown above, the pthread_self hook function actually returns the value of _current_coctx. In the program, by judging the type of the current COCTX, you can know which thread is currently in which state.

[0091] In this embodiment, the contents stored in the COCTX structure include: coroutine stack and TLS. The runtime dynamic library allocates an independent stack for each coroutine, so that the behavior of a thread can be fully simulated (including the memory size allocated in the stack and the call stack depth).

[0092] If a coroutine fails to fully simulate the thread's TLS mechanism, it will be unable to securely access variables with TLS constraints. This embodiment implements TLS management encapsulation through a synchronization management module (hereinafter referred to as co_tls). The capabilities provided by co_tls are crucial for transparent thread simulation. For example, Linux stores two types of TLS in its TCB: dtv and specific.

[0093] The disclosed co_tls support for specifics: co_tls maintains a data structure similar to the specific arrays in the TCB. When a newly created coroutine is first swapped in, the specifics in the TCB of its scheduling thread are copied. Furthermore, the library functions for managing specifics need to be hooked. The Linux library functions listed above are similar, and Windows also has similar functions: TlsAlloc, TlsFree, TlsGetValue, and TlsSetValue.

[0094] The co_tls disclosed in this invention supports dtv: Similarly, when a newly created coroutine is scheduled for execution for the first time, it is also necessary to copy the dtv in the TCB. However, unlike specific, the specific content in co_tls no longer needs to be synchronized with the TCB; but because other dynamic libraries may be dynamically loaded at runtime, the dtv of co_tls needs to be incrementally synchronized with the dtv in the TCB. We store an incremental backup of the TCB dtv in the scheduler COCTX to describe the incremental part of the dtv generated each time the dynamic library is loaded. At the same time, we need to hook the library function call that loads the dynamic library (this library function is called dlopen in Linux, and corresponds to LoadLibrary in Windows). Taking Linux as an example, a data structure called "link_map" describes all dynamic library information. Combining link_map and dtv incremental backup, the difference between the current coroutine and the dtv increment can be parsed. For the merging of dtv increments, a "lazy" synchronization solution is adopted, that is, when the coroutine is about to be swapped in, it is determined whether dtv needs to be synchronized. If dlopen is called in a coroutine, it is necessary to identify _current_coctx as a coroutine type in the dlopen hook and immediately synchronize dtv for the current coroutine.

[0095] In this embodiment, a coroutine that is completely consistent with the thread capability can be simulated through the thread scheduling library function hook. The coroutine switching process is as follows: First, in the initial state of the coroutine scheduling thread, _current_coctx is scheduler COCTX; then, when a coroutine needs to be swapped in (resume), check whether there is a difference between the coroutine and the DTV incremental backup (if there is, synchronization is required), and after the difference synchronization is completed, _current_coctx is set as the context of the current coroutine; finally, when the coroutine requires to be swapped out, _current_coctx is restored to scheduler COCTX. The entire coroutine switching process is executed entirely in user mode, without the need for any form of interaction with the operating system, thereby maintaining the lightweight characteristics of the coroutine.

[0096] Optionally, the thread scheduling library function hook also includes: a lock library function hook, in which the current running subject is judged through a global variable with a thread local constraint, and a corresponding lock mechanism is given to the current running subject based on the current running subject.

[0097] The dynamic runtime library provided in this embodiment can simulate thread creation and recycling with coroutine creation and recycling; at the same time, it provides support for coroutine swapping (i.e., simulating thread suspension and wakeup) and proper handling of TLS (thread local storage) (i.e., TLS concurrent secure access between coroutines); and based on the above capabilities, it provides support for coroutine locks and semaphores (mutex, rwlock, conditional variables, semaphore, etc.), as well as timeout wakeup (timer) mechanisms. Therefore, whether it is thread management or thread suspension / wakeup (including lock suspension, timer suspension, etc.) operations, there is no need to fall into any system call and they are implemented entirely in user mode. In the process of "transparently" replacing the runtime environment of the user-mode application with a pure user-mode environment, the solution provided by the optional implementation method of this embodiment ensures that the entire thread scheduling is "transparently" replaced with the user-mode environment.

[0098] In some optional implementations of this embodiment, as shown in Figure 2, the dynamic runtime library also includes: a memory management library function hook, which is a function related to memory management in the native library function and constructed using the HOOK mechanism. The memory management library function hook is used to enable a thread to start one or more memory allocation areas in a runtime virtual environment. The coroutines belonging to the current coroutine scheduling thread are grouped according to the memory allocation area, and the coroutines belonging to the same memory allocation area share the same coroutine scheduling thread cache.

[0099] Pure user-mode memory management can be achieved by using mmap (memory map) to pre-allocate large blocks of memory.

[0100] Specifically, mmap can map a continuous virtual address space. Furthermore, as long as the starting addresses are aligned, both user and kernel modes can directly access memory pages in their respective address spaces through the memory mapping's starting address (i.e., the same page has the same offset relative to the starting address in both user and kernel modes). Therefore, when a user-mode program accesses mmap-mapped memory, it is no different from a normal memory access, without explicitly using system calls to allocate physical memory. When an application accesses a memory address that has not yet been assigned a physical memory page, a page fault is implicitly triggered. The interrupt handler allocates physical memory and establishes a mapping relationship, without trapping the application into kernel mode. However, the physical memory allocated by the page fault mechanism may be released by the kernel or swapped out to the swap partition due to insufficient available physical memory, causing the memory page to return to a "missing" state. The next time the memory page is accessed, physical memory is reallocated to it through a page fault interrupt, or the page from the swap partition is swapped back into physical memory. To ensure that memory pages are always in place and reduce page faults (larger pages have fewer pages, with Linux typically using 2MB huge pages), pure user-mode programming frameworks often use "huge page" memory mapping to manage shared memory mappings between user and kernel mode. Huge page memory cannot be swapped out by the kernel, ensuring that its memory pages are "anchored" to the corresponding physical memory pages.

[0101] The default memory allocator in traditional virtual machines uses system calls for small memory allocations and only uses mmap for large memory allocations. Therefore, it frequently encounters system call errors when allocating memory. The memory management subsystem in this system implements pure user-mode memory management by allocating large blocks of memory entirely using mmap. This transparent replacement of the runtime environment of user-mode applications with a pure user-mode environment utilizes the solution provided by the optional implementation of this embodiment, ensuring that overall memory management is transparently replaced with user-mode memory.

[0102] In some optional implementations of this embodiment, the monitoring thread function creates a monitoring thread for each context in the asynchronous IO model after the user-mode application is started and in the runtime virtual environment. The monitoring thread is used to poll the completion queue of the asynchronous IO model. When a new ready task is received in the completion queue, the coroutine in the waiting queue corresponding to the IO operation library function hook is awakened.

[0103] The dynamic runtime library provided in this embodiment creates a background thread—a monitoring thread—for the context of the asynchronous I / O model. This monitoring thread can be one or multiple, enabling load balancing of I / O requests. The background monitoring thread repeatedly polls the asynchronous I / O model's completion queue. When a new ready task is received, it wakes up the coroutine context in the lock-free wait queue to wake up the coroutine executing the corresponding task.

[0104] The dynamic runtime library provided in this embodiment uses a monitoring thread function to generate a monitoring thread, and polls the completion queue of the asynchronous IO model through the monitoring thread, thereby improving the comprehensiveness of information obtained and ensuring the pure user-mode effect of the user-mode application.

[0105] Through the runtime virtual machine system shown in FIG2 , the present invention proposes a "transparent" pure user-mode runtime virtual machine system. By pre-loading dynamic libraries at runtime, applications can run in a pure user-mode virtualization environment without any modification to the application, thereby improving application performance. That is, the present disclosure perfectly integrates the coroutine runtime virtual machine system with pure user-mode programming technology, thereby providing a pure user-mode runtime environment that is completely "transparent" to the application.

[0106] The solution of the present invention combines coroutines (i.e., pure user-mode virtual thread scheduling), a pure user-mode memory manager based on mmap, and a pure user-mode IO subsystem based on io_uring to build a pure user-mode runtime environment that can bypass all system calls in most cases.

[0107] The solution of the present invention provides perfect compatibility with the POSIX protocol interface. Developers can use the development library based on the present invention to "transparently" develop pure user-mode applications. In other words, the present disclosure provides a development interface that integrates the native network protocol stack and file system ecosystem and is fully compatible with the POSIX protocol.

[0108] Further referring to FIG3 , as an implementation of the runtime virtual machine system shown in the above figures, the present disclosure provides an embodiment of a system operation method. FIG1 shows a process 300 of an embodiment of the system operation method according to the present disclosure, and the system operation method includes the following steps:

[0109] Step 301: Load the library file of the asynchronous IO model.

[0110] In this embodiment, the asynchronous IO model is used to enable user-mode applications and kernel-mode applications to share an IO request memory queue, thereby realizing asynchronous driving of physical devices.

[0111] In this embodiment, the library file of the asynchronous IO model implements the file of the asynchronous IO model. After the library file is loaded into the memory of the user-state application, the asynchronous model can be called when the user-state application is run.

[0112] In this embodiment, the asynchronous I / O model enables three library function calls: setting the asynchronous I / O model context; submitting and retrieving completed tasks; and registering kernel-user shared buffers via memory mapping. The calls for submitting and retrieving task completion status interact directly with the memory-mapped queue in user mode, without requiring system calls. Only asynchronous I / O context setting and file descriptor registration / unregistration require system calls.

[0113] Step 302: When starting the user-mode application, load the dynamic runtime library to generate a runtime virtualization environment.

[0114] In this embodiment, the dynamic runtime library is a dynamic library that is loaded when the user-mode application is started, and a runtime virtualization environment corresponding to the dynamic runtime library is directly generated. The runtime virtualization environment is an environment that replaces the runtime environment of the user-mode application.

[0115] In this embodiment, compiled functions are stored in a dynamic runtime library. The dynamic runtime library provides an API (Application Program Interface) to applications based on the library functions. User-mode applications issue task requests to the dynamic runtime library by calling the API. Alternatively, a dynamic runtime library can be generated by hooking the library functions related to thread scheduling in the native runtime library. Once loaded, the resulting dynamic runtime library can have scheduling capabilities equivalent to threads.

[0116] In this embodiment, the C runtime library can be fully hooked to obtain a dynamic runtime library. The dynamic runtime library provides a runtime virtualization environment, and the application runs in the runtime virtualization environment to simulate the threads implemented in the native runtime library in a coroutine manner, thereby achieving the purpose of coroutine simulation of threads and scheduling coroutines through coroutine scheduling threads.

[0117] Step 303 , in the runtime virtual environment, in response to detecting the call information of the user-mode application to the native library function of the user-mode application, the IO operation of the operating system where the user-mode application is located is converted to be processed by the asynchronous IO model through the IO operation library function.

[0118] Step 304 , in the runtime virtual environment, monitor whether the IO operation of the asynchronous IO model is completed through the monitoring thread function, and when the IO operation is completed, wake up the task in the waiting state due to the IO operation through the monitoring thread function.

[0119] The system operation method provided by the embodiment of the present disclosure first loads the library file of the asynchronous IO model; secondly, loads the dynamic runtime library when starting the user-mode application to generate a runtime virtualization environment; thirdly, in the runtime virtual environment, in response to detecting the call information of the user-mode application to the native library function of the user-mode application, converts the IO operation of the operating system where the user-mode application is located to be processed by the asynchronous IO model through the IO operation library function; finally, in the runtime virtual environment, monitors whether the IO operation of the asynchronous IO model is completed through the monitoring thread function, and when the IO operation is completed, wakes up the task that is in a waiting state due to the IO operation through the monitoring thread function. Thus, by combining dynamic injection technology with the asynchronous IO model, the encapsulation of system calls related to IO operations in the runtime library is replaced with pure user-mode technology, and the original user-mode application on the host machine runs completely "transparently" in the pure user-mode runtime environment, thereby achieving higher performance without making any modifications to the application, effectively controlling the thread resource occupancy rate in the system, reducing system resource consumption and resource scheduling pressure, and thus improving the overall throughput and availability of the system.

[0120] Further referring to FIG4 , as an implementation of the system operation method shown in the above figures, the present disclosure provides an embodiment of a system operation device. The device embodiment corresponds to the method embodiment shown in FIG3 , and the device can be specifically applied to various electronic devices.

[0121] As shown in FIG4 , an embodiment of the present disclosure provides a system operation device 400, which includes: a file loading unit 401, a library loading unit 402, a conversion unit 403, and a wake-up unit 404. The file loading unit 401 can be configured to load a library file of an asynchronous IO model. The asynchronous IO model is used to share an IO request memory queue between user-mode applications and kernel-mode to implement asynchronous driving of physical devices. The library loading unit 402 can be configured to load a dynamic runtime library when starting the user-mode application runtime to generate a runtime virtualization environment. The runtime virtualization environment is an environment that replaces the runtime environment of the user-mode application. The conversion unit 403 can be configured to, when detecting a call from a user-mode application to a native library function of the user-mode application in the runtime virtualization environment, convert the IO operation of the operating system where the user-mode application is located to be processed by the asynchronous IO model through the IO operation library function. The wake-up unit 404 can be configured to monitor whether the IO operation of the asynchronous IO model is completed through a monitoring thread function in the runtime virtualization environment, and when the IO operation is completed, wake up the task that is in a waiting state due to the IO operation through the monitoring thread function.

[0122] In this embodiment, in the device 400, the specific processing of the file loading unit 401, the library loading unit 402, and the conversion unit 403 and the technical effects brought about by them can refer to steps 301, 302, and 303 in the corresponding embodiment of Figure 1 respectively.

[0123] The system operation device provided by the embodiment of the present disclosure is as follows: first, the file loading unit 401 loads the library file of the asynchronous IO model; second, the library loading unit 402 loads the dynamic runtime library when starting the user-mode application to generate a runtime virtualization environment, which is an environment that replaces the runtime environment of the user-mode application; then, the conversion unit 403 detects the call information of the user-mode application to the native library function of the user-mode application in the runtime virtual environment, and converts the IO operation of the operating system where the user-mode application is located into processing by the asynchronous IO model through the IO operation library function. Finally, the wake-up unit monitors whether the IO operation of the asynchronous IO model is completed by monitoring the thread function in the runtime virtual environment, and when the IO operation is completed, wakes up the task that is in a waiting state due to the IO operation through the monitoring thread function. Therefore, by combining dynamic injection technology with the asynchronous IO model, the encapsulation of system calls related to IO operations in the runtime library is implemented using pure user-mode technology, and the original user-mode applications on the host machine run completely "transparently" in a pure user-mode runtime environment, thereby achieving higher performance without making any modifications to the applications. This can effectively control the thread resource occupancy rate in the system, reduce system resource consumption and resource scheduling pressure, and thus improve the overall system throughput and availability.

[0124] 5 , which shows a schematic structural diagram of an electronic device 500 suitable for implementing the embodiments of the present disclosure.

[0125] As shown in Figure 5, the electronic device 500 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage device 508 into a random access memory (RAM) 503. Various programs and data required for the operation of the electronic device 500 are also stored in the RAM 503. The processing device 501, the ROM 502, and the RAM 503 are connected to each other via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0126] Typically, the following devices can be connected to the I / O interface 505: an input device 506 including, for example, a touch screen, a touchpad, a keyboard, a mouse, etc.; an output device 507 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 508 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 509. The communication device 509 can allow the electronic device 500 to communicate with other devices wirelessly or by wire to exchange data. Although Figure 5 shows an electronic device 500 with various devices, it should be understood that it is not required to implement or have all the devices shown. More or fewer devices may be implemented or have alternatively. Each box shown in Figure 5 may represent one device, or may represent multiple devices as needed.

[0127] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network via the communication device 509, or installed from the storage device 508, or installed from the ROM 502. When the computer program is executed by the processing device 501, the above-mentioned functions defined in the method of the embodiment of the present disclosure are performed.

[0128] It should be noted that the computer-readable medium of the embodiments of the present disclosure may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or component, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the embodiments of the present disclosure, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device, or component. In the embodiments of the present disclosure, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal may take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or convey a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code embodied on the computer-readable medium may be conveyed using any suitable medium, including but not limited to wires, optical cables, RF (Radio Frequency), or any suitable combination thereof.

[0129] The computer-readable medium may be included in the server, or may exist independently without being installed in the server. The computer-readable medium carries one or more programs. When the one or more programs are executed by the server, the server: loads the library file of the asynchronous IO model, which is used to share the IO request memory queue between the user-mode application and the kernel mode to achieve asynchronous driving of the physical device; when the user-mode application is started, loads the dynamic runtime library and generates a runtime virtualization environment, which is an environment that replaces the runtime environment of the user-mode application; in the runtime virtual environment, in response to detecting the IO operation library function hook call information that is compatible with the asynchronous IO model in the dynamic runtime library, the IO operation of the operating system where the user-mode application is located is converted to be processed by the asynchronous IO model through the IO operation library function.

[0130] Computer program code for performing the operations of embodiments of the present disclosure may be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0131] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to the various embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the module, program segment, or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of the boxes in the block diagram and / or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0132] The units involved in the embodiments described in the present disclosure can be implemented by software or by hardware. The described units can also be set in a processor. For example, they can be described as: a processor including a file loading unit, a library loading unit, and a conversion unit. In some cases, the names of these units do not constitute a limitation on the units themselves. For example, the file loading unit can also be described as a unit "configured to load a library file of an asynchronous IO model."

[0133] The above description is merely a preferred embodiment of the present disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of the present disclosure is not limited to the technical solutions formed by a specific combination of the above-mentioned technical features, but should also encompass other technical solutions formed by any combination of the above-mentioned technical features or their equivalents without departing from the above-mentioned inventive concept. For example, a technical solution formed by mutually replacing the above-mentioned features with (but not limited to) technical features with similar functions disclosed in the embodiments of the present disclosure.

Claims

1. A runtime virtual machine system, the system comprising: User-mode applications; An asynchronous input-output (IO) model is used to enable the user-mode application and the kernel-mode to share an IO request memory queue to achieve asynchronous driving of a physical device; as well as A dynamic runtime library that can be loaded when the user-mode application is started, the dynamic runtime library is used to generate a runtime virtual environment that replaces the runtime environment of the user-mode application after being loaded; wherein the dynamic runtime library includes an IO operation library function hook and a monitoring thread function; The IO operation library function hook is constructed based on the native library function of the user-state application, and the IO operation library function is used to adapt the application program interface of the native library function and the asynchronous IO model in the runtime virtual environment, and convert the IO operation of the operating system where the user-state application is located into processing by the asynchronous IO model; The monitoring thread function is used to monitor whether the IO operation of the asynchronous IO model is completed in the runtime virtual environment, and when the IO operation is completed, wake up the task that is in a waiting state due to the IO operation.

2. The system according to claim 1, wherein: The IO operation library function hook includes: a file descriptor management hook function, a file descriptor read and write hook function, and a voting (POLL) state hook function; The file descriptor management hook function is used to create a file descriptor in the runtime virtual environment, put the file descriptor into the file descriptor table, and register the file descriptor in the asynchronous IO model; The file descriptor management hook function is also used to deregister the file descriptor from the asynchronous IO model when the file descriptor is closed in the runtime virtual environment; The file descriptor read and write hook function is used to receive a read request or a write request for the file descriptor under the runtime virtual environment, and place the read request or the write request Enter the submission queue of the asynchronous IO model; The POLL state hook function is used to receive a POLL wait request or a POLL wake-up request under the runtime virtual environment, and put the POLL wait request or the POLL wake-up request into the submission queue of the asynchronous IO model.

3. The system according to claim 1, wherein: The dynamic runtime library uses coroutines to simulate threads implemented in native library functions, and the IO operation library function hooks include: file IO hook functions and file IO callback functions, network IO hook functions and network IO callback functions; The file IO hook function is a function constructed by using a hook mechanism and is related to the file IO library function in the native library function; The network IO hook function is a function constructed by using the HOOK mechanism and is related to the network IO library function in the native library function; the file IO hook function and the network IO hook function are used to determine whether the operation subject is a coroutine when suspending or waiting for the IO operation to be completed in the runtime virtual environment, and if it is a coroutine, the coroutine is suspended by using a coroutine switching or suspension mechanism; The file IO callback function is used to change the IO-related operations in the file IO hook function to be synchronized with the asynchronous IO model under the runtime virtual environment; The network IO callback function is used to change the IO-related operations in the network IO hook function to be synchronized with the asynchronous IO model under the runtime virtual environment.

4. The system according to claim 1, wherein the dynamic runtime library further comprises: A thread scheduling library function hook, wherein the thread scheduling library function hook is a function related to the thread creation, recycling and suspension library functions in the native library function constructed using the HOOK mechanism. The thread creation, recycling and suspension library functions are functions in the native runtime library of the application that can create, recycle and suspend threads. The thread scheduling library function hook is used to replace the creation and recycling of threads with the creation and recycling of coroutines in the runtime virtual environment, and after the application is running, generate a coroutine scheduling thread to schedule at least one coroutine through the coroutine scheduling thread.

5. The system according to claim 3, wherein the dynamic runtime library further comprises: A memory management library function hook is a function related to memory management in the native library function and constructed using the HOOK mechanism. The memory management library function hook is used to enable a thread to start one or more memory allocation areas in the runtime virtual environment. The coroutines belonging to the current coroutine scheduling thread are grouped according to the memory allocation areas, and the coroutines belonging to the same memory allocation area share the same coroutine scheduling thread cache.

6. According to the system of any one of claims 3-5, the monitoring thread function creates a monitoring thread for each context in the asynchronous IO model after the user-mode application is started and in the runtime virtual environment, and the monitoring thread is used to poll the completion queue of the asynchronous IO model, and when a new ready task is received in the completion queue, the coroutine in the waiting queue corresponding to the IO operation library function hook is woken up.

7. A system operation method, the method comprising: Loading a library file of an asynchronous IO model, wherein the asynchronous IO model is used to enable a user-mode application to share an IO request memory queue with a kernel-mode application to implement asynchronous driving of a physical device; When starting the user state application to run, loading the dynamic runtime library to generate a runtime virtualization environment, wherein the runtime virtualization environment is an environment that replaces the runtime environment of the user state application; In the runtime virtual environment, in response to detecting call information of the user-state application to the native library function of the user-state application, converting the IO operation of the operating system where the user-state application is located into processing by the asynchronous IO model through the IO operation library function; In the runtime virtual environment, whether the IO operation of the asynchronous IO model is completed is monitored by a monitoring thread function, and when the IO operation is completed, the task in a waiting state due to the IO operation is awakened by the monitoring thread function.

8. A system operation device, the device comprising: The file loading unit is configured to load a library file of an asynchronous IO model. The model is used to share the IO request memory queue between user-mode applications and kernel-mode to implement asynchronous driving of physical devices; A library loading unit is configured to load a dynamic runtime library and generate a runtime virtualization environment when starting the runtime of the user-mode application, wherein the runtime virtualization environment is an environment that replaces the runtime environment of the user-mode application; A conversion unit is configured to convert an IO operation of the operating system where the user-state application is located into processing by the asynchronous IO model through an IO operation library function when the user-state application detects call information of the native library function of the user-state application in the runtime virtual environment; The wake-up unit is configured to monitor whether the IO operation of the asynchronous IO model is completed through a monitoring thread function in the runtime virtual environment, and when the IO operation is completed, wake up the task in the waiting state due to the IO operation through the monitoring thread function.

9. An electronic device, comprising: one or more processors; a storage device having one or more programs stored thereon; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as claimed in claim 7.

10. A computer readable medium having a computer program stored thereon, wherein: When the program is executed by a processor, the method according to claim 7 is implemented.

Images