Runtime virtual machine system, system running method and device

Abstract

The present disclosure provides a runtime virtual machine system. A specific implementation of the system includes: a user-space application; an asynchronous I / O model for sharing an I / O request memory queue between the user-space application and the kernel space; a dynamic runtime library that can be loaded when the user-space application starts, and after loading the dynamic runtime library, generates a runtime virtual environment that replaces the runtime environment of the user-space application; the dynamic runtime library includes an I / O operation library function hook; the I / O operation library function hook is constructed based on the native library functions of the user-space application, and the I / O operation library function is used to adapt the application program of the native library function and the asynchronous I / O model in the runtime virtual environment, and convert the I / O operations of the operating system where the user-space application is located into being processed by the asynchronous I / O model. This implementation can "transparently" replace the runtime environment of the application program with a pure user-space environment, and realize pure user-space I / O operations.

Description

Technical Field

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

[0002] In the existing runtime virtual machine technology, it is generally developed based on the C runtime library. Each operating system provides encapsulation of system calls through the C runtime library. Application programs executed in various runtime virtual machine environments actually need to call the system calls of the host operating system to implement underlying IO operations. However, compared with user-mode code, the cost of executing system calls is extremely high. Summary of the Invention

[0003] 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.

[0004] In a first aspect, an embodiment of the present disclosure provides a runtime virtual machine system, which includes: a user-mode application program; an asynchronous IO model for sharing an IO request memory queue between the user-mode application program and the kernel mode to implement asynchronous driving of physical devices; a dynamic runtime library that can be loaded when the user-mode application program is started. After loading the dynamic runtime library, a runtime virtual environment that replaces the runtime environment of the user-mode application program is generated; 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-mode application program. 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-mode application program is located into being 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.

[0005] In some embodiments, the above-mentioned IO operation library function hooks include: a file descriptor management hook function, a file descriptor read / write hook function, and a POLL status 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 to the asynchronous IO model; the file descriptor management hook function is also used to unregister the file descriptor from the asynchronous IO model in the runtime virtual environment when the file descriptor is closed; the file descriptor read / 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.

[0006] In some embodiments, the above-mentioned dynamic runtime library uses coroutines to simulate the threads implemented in the native library functions. The IO operation library function hooks include: a file IO hook function and a file IO callback function, a network IO hook function and a network IO callback function; the file IO hook function is a function constructed using the HOOK mechanism and related to the file IO library function in the native library function; the network IO hook function is a function constructed using the HOOK mechanism and 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 completion of an IO operation in the runtime virtual environment. If it is a coroutine, the coroutine switching or suspension mechanism is used to suspend the coroutine; the file IO callback function is used to synchronize the IO-related operations in the file IO hook function with the asynchronous IO model in the runtime virtual environment; the network IO callback function is used to synchronize the IO-related operations in the network IO hook function with the asynchronous IO model in the runtime virtual environment.

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

[0008] In some embodiments, the above dynamic runtime library further 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 a runtime virtual environment. The coroutines belonging to the current coroutine scheduling thread are grouped by memory allocation area, and the coroutines belonging to the same memory allocation area share the same coroutine scheduling thread cache.

[0009] 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, and when a new ready task is received in the completion queue, it wakes up the coroutines in the waiting queue corresponding to the IO operation library function hook.

[0010] In a second aspect, an embodiment of the present disclosure provides a system operation method, which includes: loading a library file of an asynchronous IO model, where the asynchronous IO model is used to enable a user-mode application to share an IO request memory queue with the kernel mode to achieve 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, where the runtime virtualization environment is an environment that replaces the runtime environment of the user-mode application; in the runtime virtual environment, in response to detecting a call message of the native library function of the user-mode application by the user-mode application, converting the IO operation of the operating system where the user-mode application is located into an operation processed by the asynchronous IO model through the IO operation library function;

[0011] In the runtime virtualization environment, monitoring whether the IO operation of the asynchronous IO model is completed through the monitoring thread function, and when the IO operation is completed, waking up the tasks in the waiting state due to the IO operation through the monitoring thread function.

[0012] 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, where the asynchronous IO model is used to enable a user-space application to share an IO request memory queue with a kernel-space to implement asynchronous driving of a physical device; a library loading unit configured to load a dynamic runtime library when starting the user-space application to run, generate a runtime virtualization environment, and the runtime virtualization environment is an environment that replaces the runtime environment of the user-space application; a conversion unit configured to, in the runtime virtual environment and when detecting a call information of a native library function of the user-space application by the user-space application, convert an IO operation of the operating system where the user-space application is located into an operation processed by the asynchronous IO model through an IO operation library function; a wake-up unit configured to, in the runtime virtual environment, monitor whether an IO operation of the asynchronous IO model is completed through a monitoring thread function, and when the IO operation is completed, wake up a task that is in a waiting state due to the IO operation through the monitoring thread function.

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

[0014] In a fifth aspect, an embodiment of the present disclosure provides a computer-readable medium storing a computer program thereon, and when the program is executed by a processor, the method described in any one of the embodiments in the second aspect is implemented.

[0015] The runtime virtual machine system provided by the embodiments of the present disclosure includes: a user-mode application; an asynchronous I / O model for sharing an I / O request memory queue between the user-mode application and the kernel-mode to achieve asynchronous driving of physical devices; a dynamic runtime library that can be loaded when the user-mode application starts. After loading the dynamic runtime library, a runtime virtual environment is generated to replace the runtime environment of the user-mode application. The dynamic runtime library includes an I / O operation library function hook and a monitoring thread function. The I / O operation library function hook is constructed based on the native library functions of the user-mode application. The I / O operation library function is used to adapt the application programming interface of the native library function and the asynchronous I / O model in the runtime virtual environment, and convert the I / O operations of the operating system where the user-mode application is located into those processed by the asynchronous I / O model. The monitoring thread function is used to monitor whether the I / O operations of the asynchronous I / O model are completed in the runtime virtual environment, and wake up the tasks waiting due to the I / O operations when the I / O operations are completed. Thus, after the runtime dynamic library of the present disclosure is started by the user-mode application, it is loaded into the memory of the user-mode application to generate a runtime virtual environment. Through the runtime virtual environment, the runtime environment of the native runtime library of the user-mode application can be directly replaced, the I / O operations of the operating system where the user-mode application is located are taken over, and the I / O operations are converted into those processed by the asynchronous I / O model. By processing the I / O operations through the asynchronous I / O model, the number of system calls is reduced, and the I / O performance is improved; through the dynamic injection technology, without any modification to the application, the user-mode application has the pure user-mode I / O ability, saving labor costs and improving the convenience of operating the user-mode application. Description of the Drawings

[0016] By reading the detailed description of the non-limiting embodiments with reference to the following drawings, other features, objectives, and advantages of the present disclosure will become more apparent:

[0017] Figure 1 It is a schematic structural diagram of an embodiment of the runtime virtual machine system according to the present disclosure;

[0018] Figure 2 It is a schematic structural diagram of another embodiment of the runtime virtual machine system according to the present disclosure;

[0019] Figure 3 It is a flowchart of an embodiment of the system operation method according to the present disclosure;

[0020] Figure 4 It is a schematic structural diagram of an embodiment of the system operation device according to the present disclosure;

[0021] Figure 5 It is a schematic structural diagram of an electronic device suitable for implementing the embodiments of the present disclosure. Detailed Embodiments

[0022] The present disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. It can be understood that the specific embodiments described herein are only used to explain the relevant invention and do not limit the invention. In addition, it should be noted that for the sake of description, only parts related to the relevant invention are shown in the drawings.

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

[0024] A runtime virtual machine system is often used to provide cross-platform support or provide a virtualized runtime environment, and dynamic library injection is a technical solution that can be used to implement a runtime virtual machine. Inject a dynamic library into an application, and this dynamic library overwrites the functions in the original application and the functions in the dynamic libraries linked by the original application with its function hooks.

[0025] Application programs executed in various runtime virtual machine environments need to call the system calls of the host operating system. However, the cost of executing system calls is extremely high because: on the one hand, entering and returning from a system call means a switch from the user mode to the kernel mode and a switch from the kernel mode to the user mode; on the other hand, the user-mode virtual address space and the kernel-mode address space are isolated from each other, so memory access cannot be directly performed between the user mode and the kernel mode, and memory copying is required. Given the high cost of system calls, some high-performance pure user-mode programming models have been proposed to improve the performance of application programs and achieve higher IO throughput by executing as few system calls as possible (let the application program run in the user mode most of the time without any user-mode / kernel-mode switches).

[0026] In view of the fact that some of the existing pure user-mode programming models do not have a complete network protocol stack and file system ecosystem, and some do not provide complete support for application interfaces, code modification is required when an application program is accessed, which is complex to implement, difficult to operate, and has a large labor cost.

[0027] To better understand the traditional technology, some terms will be introduced below:

[0028] Dynamic library (Shared library): Also known as "dynamic link library", it is a way to implement shared functions or objects in an operating system. Compiled functions are stored in the dynamic library, and application programs can dynamically load such library files and reference the corresponding functions by function names; the same dynamic library can be loaded by different application programs.

[0029] C runtime library: A general term for a class of dynamic link libraries that provide encapsulation for system calls and various operating system management interfaces, and offer a C-language programming interface for the interaction between application programs and the operating system during runtime. Application programs can be directly built based on the C runtime library or run on a runtime virtual machine built on a certain 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", and the C runtime library in the Android distribution is called "bionic". In the Windows system, the C runtime library is called the CRT library.

[0030] Runtime virtual machine: A general term for a program and library that provides a development interface and a runtime environment for other application programs. Such programs are generally developed based on the C runtime library and aim to provide a cross-platform program runtime environment. Compared with a "virtual machine", a runtime virtual machine does not fully simulate a virtual host but only provides a runtime environment, so it is lighter.

[0031] Dynamic library injection: Reverse modifying a third-party application to make it execute the injected code, this behavior is called "code injection"; and dynamic library injection is a way to achieve code injection. The so-called "dynamic library injection" is to inject the code in the dynamic library into the target application by loading the dynamic library into the application program, so that this part of the code is executed by the application, or dynamically replace the original code in the application with the injected code.

[0032] Kernel mode and user mode: To ensure the security of system operation, generally modern CPUs have several different instruction levels. At a high execution level, the code can execute privileged instructions and access any physical address, and this running level corresponds to the kernel mode of the operating system. At a low execution level, the control range of the code is restricted and can only operate within the range permitted by the corresponding level, and this running level corresponds to the user mode. When a user-mode program needs to run the functions provided by the operating system kernel, it can switch from the user mode to the kernel mode by executing the corresponding system call and run the high-execution-level code in the kernel mode.

[0033] User-mode drivers: Device drivers typically run in kernel space. However, with the continuous development of software and hardware technologies, when attempting to provide high-concurrency connection server capabilities, the drawbacks of kernel-mode drivers begin to gradually emerge. For example, the huge overhead of system calls (each device access by an application must go through a system call), the extremely high requirements for driver stability (since kernel-mode errors can directly cause the system to crash), the steep learning curve for developers, and the instability of development interfaces (when the kernel version is upgraded and the kernel driver interface changes, the driver needs to be re-adapted to the new version of the kernel), and so on. Therefore, hardware companies such as Intel, Texas Instruments, and Freescale have then started to study this issue and provide user-mode driver solutions for their hardware.

[0034] DPDK and SPDK: DPDK (Data Plane Development Kit) is a user-mode network card driver solution. DPDK defines a set of running environments, and this environment defines a kernel thread for each CPU core. To ensure maximum 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 kernel. Therefore, kernel threads will occupy CPU computing power. The more kernel threads are started, the higher the parallel throughput capacity of the network device, but the more computing power is occupied. And SPDK (Storage Performance Development Kit) is a set of user-mode storage device driver suites developed based on DPDK, aiming to provide high-performance driver solutions for its high-speed storage devices.

[0035] Io_uring technology: A new type of asynchronous I / O model. Io_uring mainly aims to solve problems such as large overhead of system calls and memory copying, only supporting direct I / O, and having size alignment restrictions on data. It uses memory mapping technology to create a shareable circular memory queue between user space and kernel space, and achieves the purpose of reducing system calls and memory copying through shared memory communication. Ideally, zero-system-call I / O access can be achieved.

[0036] Co-routine: Also known as "Fiber thread" or "Micro thread", it is a computer component that generates non-preemptive multi-task subroutines. A co-routine generally attaches to a certain thread, allowing different subroutine entrances to pause or start at the same position; simply put, a co-routine is a function that can pause and start. Different co-routines can be regarded as different functions and are called and executed by the host thread; during the execution process, a co-routine can return to the position where the host thread called the co-routine by actively yielding (i.e., "yield"); and when the host thread calls the co-routine function again (i.e., "resume"), the co-routine will continue to execute from the previous yield point.

[0037] Thread local storage (TLS): Also known as thread local storage, it is a solution to thread safety issues in specific scenarios. Simply put, it is a variable with a process-wide scope. When it has a thread local constraint, this variable can have different values (i.e., thread local values) in different threads. TLS is divided into two types and three situations according to the implementation method. The first type is the variable declared with a thread local constraint during coding. For example:

[0038] static __thread int global_tls_value = 0;

[0039] The above variable declaration represents a global integer variable with an initial value of 0. This variable can be accessed in all threads of the program where it is located; however, changes to the value of this variable by different threads are only visible to the current thread. This type of TLS variable can determine its position in the program's data segment and its initial value during the compilation stage. Therefore, its relevant information and initial value will be stored in the compiled target program, and when the program is loaded, its position in the thread local context will be locked. Another situation is that when the program loads a certain dynamic library during operation, if there are also TLS variables in the dynamic library, the positions of these TLSs in the thread local context need to be dynamically determined again when the dynamic library is loaded. In addition to the TLS variables declared during coding, there is a second type, which is dynamically created TLS.

[0040] The present disclosure provides a runtime virtual machine system, such as Figure 1, which shows a schematic structural diagram of an embodiment of a runtime virtual machine system according to the present disclosure. The runtime virtual machine system 100 includes: a user-mode application 101, an asynchronous IO model 102, and a dynamic runtime library 103. Among them, the asynchronous IO model 102 is used to share an IO request memory queue between the user-mode application 101 and the kernel mode to achieve asynchronous driving of physical devices.

[0041] The dynamic runtime library 103 is loaded into the memory of the user-mode application 101 when the user-mode application starts. After loading the dynamic runtime library, a runtime virtual environment that replaces the runtime environment of the user-mode application is generated; 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 functions of the user-mode application. The IO operation library function 1031 is used to adapt the application program interface of the native library function and the asynchronous IO model 102 in the runtime virtual environment, and convert the IO operations of the operating system where the user-mode application is located into being processed by the asynchronous IO model.

[0042] 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 tasks waiting due to this IO operation when the IO operation is completed.

[0043] In this embodiment, the user-mode application 101 is an application running in the user mode. The user mode is the space provided for the application to run. Generally, all applications can only run in the user mode. The native library functions of the user-mode application are functions compiled in the native C runtime library of the user-mode application. The native runtime library is a dynamic link library that the user application needs to call to implement its functions. Compared with the dynamic runtime library of the present disclosure, the application needs to call the system calls of the host operating system multiple times, and the cost of system calls is relatively high.

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

[0045] In this embodiment, when there is an IO operation in the operating system where the user-mode application is located, the library functions during the runtime of the dynamic runtime library 103 can directly convert this IO operation into being processed by the asynchronous IO model.

[0046] In this embodiment, the asynchronous IO model 102 is a model implemented based on memory mapping technology. The asynchronous IO model enables the application program not to get stuck in any system calls during memory allocation or release, thereby improving the efficiency of memory allocation or release.

[0047] In this embodiment, the asynchronous IO model 102 can adopt io_uring, which also uses memory mapping technology to share the IO cache between the user space and the kernel space. As the name implies, the memory cache of io_uring is a "circular queue". The application program can also realize data interaction with the device by looping through the state of the memory cache in the circular queue. Different from DPDK that directly drives physical devices, io_uring can access devices or files based on file handles (that is, it supports the kernel protocol stack and the file system). io_uring encapsulates all operations of accessing the kernel protocol stack and the file system asynchronously inside the kernel. The IO operations initiated by the application program through io_uring will not get stuck in system calls at all, nor is it necessary to perform memory copying with the kernel.

[0048] In this embodiment, the asynchronous IO model includes: a submission queue (Submission Queue, SQ) and a completion queue (Completion Queue, CQ); among them, the submission queue is a circular queue stored in a whole continuous memory space, used to store the data for performing I / O operations. The data is the index pointing to the submission queue entry array (Submission Queue Entry, SQE), and the submission queue entry data is an item in the submission queue. Completion queue: a circular queue stored in a whole continuous memory space, used to store the results returned after the I / O operation is completed.

[0049] Optionally, the asynchronous IO model can also adopt DPDK or SPDK that has completed the kernel protocol stack and the file system. DPDK / SPDK is an asynchronous model implemented entirely in the user space. However, the file system and protocol stack ecosystems of the two are incomplete. Through code development by the program developer for DPDK or SPDK, it is possible to access devices or files based on file handles (that is, to implement a system equivalent to the kernel protocol stack and the kernel file system in the user space). The specific code development process will not be elaborated here.

[0050] 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 situation of the asynchronous IO model performing IO operations in real time. When the IO operation is completed, it wakes up the tasks waiting due to this IO operation, ensuring the effective execution of the tasks.

[0051] The runtime virtual machine system provided by the embodiments of the present disclosure includes: a user-mode application; an asynchronous IO model for sharing an IO request memory queue between the user-mode application and the kernel mode to achieve asynchronous driving of physical devices; a dynamic runtime library that can be loaded when the user-mode application starts, 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-mode 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 operations of the operating system where the user-mode application is located into those processed by the asynchronous IO model; the monitoring thread function is used to monitor whether the IO operations of the asynchronous IO model are completed in the runtime virtual environment, and wake up the tasks waiting due to the IO operations when the IO operations are completed. Thus, after the runtime dynamic library of the present disclosure is loaded into the memory of the user-mode application after the user-mode application starts, it can directly replace the native runtime library of the user-mode application, take over the IO operations of the operating system where the user-mode application is located, and convert the IO operations into those processed by the asynchronous IO model. By processing the IO operations through the asynchronous IO model, the number of system calls is reduced, and the IO performance is improved; through the dynamic injection technology, without making any modifications to the application program, the user-mode application has the pure user-mode IO ability, saving labor costs and improving the convenience of operating the user-mode application.

[0052] In some alternative implementation manners of the present disclosure, the above-mentioned IO operation library function hook includes: a file descriptor management hook function, a file descriptor read / write hook function, and a POLL status hook function.

[0053] 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 to the asynchronous IO model; the file descriptor management hook function is also used to unregister the file descriptor from the asynchronous IO model and release the corresponding content in the file descriptor table for the file descriptor when closing the file descriptor in the runtime virtual environment.

[0054] The above-mentioned file descriptor read / 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.

[0055] The above-mentioned 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.

[0056] 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. The file descriptor management hook function has the ability to communicate with the asynchronous IO model compared to the file descriptor management function in the native library function, and can register or unregister a file descriptor to / from the asynchronous IO model; the file descriptor read / write hook function can put the read request and write request of a file descriptor into the submission queue of the asynchronous IO model compared to the file descriptor read / write function in the native library function, enabling the read and write of the file descriptor to be in the user state, further reducing system calls and improving IO performance; 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 compared to the POLL status function in the native library function, further reducing system calls and improving IO performance.

[0057] In some optional implementation manners of the present disclosure, the dynamic runtime library uses coroutines to simulate the threads implemented in the native library function. The IO operation library function hook includes: a file IO hook function, a file IO callback function, a network IO hook function, and a network IO callback function.

[0058] 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 the runtime virtual environment. If it is a coroutine, the coroutine switching or suspension mechanism is used to suspend the coroutine.

[0059] Among them, the above file IO hook function is a function constructed using the HOOK mechanism and related to the file IO library function in the native library function; when the native library function is a function of the C runtime library, the functions related to the file IO library function in the native library function include: lseek, read / write, readv / writev, etc. The file IO hook function will determine whether the current context is in the thread state. If it is a thread, the native system call or library function is called; if it is a coroutine, the logic of the file IO hook function itself needs to be used.

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

[0061] For system native threads (including the main thread), there is no problem with blocking and suspending the current thread. Therefore, in the network I / O hook function, it will judge whether the current context is in the thread state during the suspension or wake-up operation. If it is a thread, the suspension or wake-up mechanism of the thread will be adopted, that is, the thread is suspended or woken up; if it is a coroutine, the suspension or wake-up mechanism of the coroutine will be adopted, that is, coroutine yield / resume.

[0062] When a coroutine calls library functions such as send / recv and tries to enter a blocking wait, the network I / O hook function manages the file descriptor through the UrFd structure and the POLL state corresponding to the file descriptor. If the corresponding receive or send buffer is not ready, it marks that the current coroutine context enters the I / O wait on this socket and yields in the form of yield.

[0063] Similarly, when a coroutine calls library functions such as poll and tries to wait for the readiness of certain socket states, the network I / O hook function will judge from the UrFd table whether there are any sockets that are already in the ready state among these sockets. If so, it will return immediately; if not, it will mark the I / O wait state of the current coroutine context on all sockets monitored in this poll operation and yield in the form of yield.

[0064] When the background epoll thread receives a batch of socket ready signals, it will check whether there is a coroutine context that marks the I / O wait state on these sockets. If so, it will wake up these coroutines in batches.

[0065] There is a hook function in the dynamic runtime library to generate a coroutine scheduling thread. After the coroutine scheduling thread is generated, each coroutine scheduling thread maintains a lock-free wakeup queue. Waking up a certain coroutine means putting the coroutine context of this coroutine into the wakeup queue of its corresponding scheduling thread.

[0066] In this embodiment, the execution entity uses its own UrFd structure and UrFd table (which is also a lock-free hash table) to manage the opened file descriptors. The UrFd structure at least includes the following three fields: the first is the file descriptor (which is also the primary key of the UrFd table); the second is the poll status of the file; the third is the lock-free waiting queue. Different from the virtual machine system generated by the file IO hook function and the network IO hook function, in the IO hook function of this virtual machine system, the library function will only be taken over in the coroutine context state; in the thread context state, it still realizes through the execution of system calls. However, the core goal of this embodiment is to build a "pure user-mode" runtime environment. Therefore, even in the thread context state, it needs to be implemented in a pure user-mode way, that is, by converting the IO operation into an asynchronous IO model to improve the overall performance as much as possible with a pure user-mode solution. In the UrFd structure of the present disclosure, the lock-free waiting queue is used to maintain the situation where multiple coroutines (or threads) are stuck in poll waiting or IO waiting on the same file descriptor.

[0067] In this embodiment, the file IO callback function is used to synchronize the IO-related operations in the file IO hook function with the asynchronous IO model in the runtime virtual environment; through the file IO callback function, the file IO library function can be taken over and docked with the asynchronous IO model to achieve the purpose of synchronizing with the asynchronous IO model. Specifically, the file IO callback function includes: a first callback function related to reading the file descriptor. After receiving a read request related to the file descriptor, the first callback function submits the read request to the submission queue of the asynchronous IO model, puts the current coroutine context into the waiting queue of the corresponding file descriptor, and yields (or suspends the thread) to give up. When receiving the ready message of the asynchronous IO model, set the status of the file descriptor and wake up the coroutines (or threads) in the waiting queue of the file descriptor. Among them, the waiting queue of the file descriptor is a lock-free queue structure that supports waiting with timeout / without timeout and also supports coroutine swapping out and thread suspension.

[0068] The file I / O callback function further includes: a second callback function related to writing of the file descriptor, which is used to submit the write request related to the file descriptor to the submission queue of the asynchronous I / O model after receiving the write request related to the file descriptor, by putting the current coroutine context into the waiting queue of the corresponding file descriptor and yielding (or suspending the thread). When receiving the message that the asynchronous I / O model is ready, set the status of the file descriptor and resume the coroutine (or thread) in the waiting queue of the file descriptor.

[0069] The network I / O callback function is used to synchronize the I / O-related operations in the network I / O hook function with the asynchronous I / O model in the runtime virtual environment; through the network I / O callback function, the network I / O library functions can be taken over and docked with the asynchronous I / O model to achieve the purpose of synchronizing with the asynchronous I / O model.

[0070] In this embodiment, the network I / O callback function includes: a second callback function related to file descriptor management (creation or closing), and a third callback function related to POLL waiting. Among them, the second callback function is started when creating or closing a file descriptor, creates a UrFd structure for the newly created file descriptor, puts it into the UrFd table, and registers the file descriptor into the asynchronous I / O model; when closing the file descriptor, unregister the file descriptor from the asynchronous I / O model and release the UrFd structure corresponding in the UrFd table.

[0071] When the POLL status is not ready, the third callback function submits the POLL status request to the submission queue of the asynchronous I / O model, puts the current coroutine context into the waiting queue of the UrFd, and yields (or suspends the thread). The waiting operation with timeout is implemented through a lock-free timeout queue.

[0072] The dynamic runtime library provided in this embodiment realizes the simulation of threads in the native library functions in file I / O and network I / O through the file I / O hook function and the network I / O hook function, takes over the functions of the file I / O hook function through the file I / O callback function and realizes the docking with the asynchronous I / O model, takes over the network I / O hook function through the network I / O callback function and realizes the docking with the asynchronous I / O model, enhances the user-mode effect of the runtime environment of the runtime virtual machine system, reduces system calls, and improves I / O performance.

[0073] In some optional implementation manners of this embodiment, such as Figure 2As shown in the figure, the dynamic runtime library further includes: a thread scheduling library function hook, which is a function related to thread creation, recycling, and suspension library functions in the native library function constructed by 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 runs, so as to schedule at least one coroutine through the coroutine scheduling thread.

[0074] In this embodiment, when the user-mode application is started, the dynamic runtime library is loaded, and a coroutine scheduling thread can be generated.

[0075] Among them, the coroutine scheduling thread includes: a scheduler and a lock-free queue for placing at least one coroutine. The specific steps for the coroutine scheduling thread to schedule at least one coroutine are as follows: the scheduler obtains the coroutine in the ready state from the lock-free queue among at least one coroutine; synchronizes the coroutine context of the coroutine with the thread context in the thread control block; after the coroutine actively yields, 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 actively yields, the scheduler continues to obtain coroutines from the lock-free queue and synchronize the thread control block until there are no coroutines in the lock-free queue.

[0076] In this embodiment, the thread control block is the data structure of the thread in the native runtime library, called the "Thread Control Block" (abbreviated as TCB), that is, the context structure of the thread. dtv and specific array are the data structures for storing TLS data in the TCB. dtv: used to store the TLS variables defined in the encoding stage. This data will increase incrementally as the application loads new dynamic libraries, because there may also be TLS variables in the dynamic libraries.

[0077] specific: Dynamically created TLS (where the library functions for creating and deleting TLS keys are pthread_key_create and pthread_key_delete respectively; and the library functions for reading and modifying TLS values are pthread_getspecifix and pthread_setspecific respectively). This type of TLS is maintained by a group of pointer arrays (specific arrays), so the number has an upper limit (Linux supports creating up to 1024 dynamic TLSs at most).

[0078] In this embodiment, the scheduler will perform incremental synchronization of TLS data between the TCB and the coroutine context.

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

[0080] The coroutine context structure (hereinafter referred to as the 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 and is similar to the role of a thread descriptor (or thread handle). 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 named "pthread". The calls for creating threads and obtaining thread descriptors in Linux are respectively:

[0081] pthread_create: Creates a thread and returns the thread descriptor, and the value of this thread descriptor is the address of the TCB structure. In this embodiment, the hook of the thread creation function instead returns a pointer to COCTX.

[0082] pthread_self: Obtains the descriptor of the current thread, which is also replaced by a pointer to COCTX.

[0083] 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, and its declaration is as follows:

[0084] extern __thread COCTX* _current_coctx;

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

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

[0087] Global COCTX: The _current_coctx of the main thread will be set to global COCTX, and this COCTX will be created when the dynamic library is just loaded during operation.

[0088] Scheduler COCTX: Each coroutine scheduling thread (i.e., the thread that runs coroutines) will have a default COCTX. When no coroutine is in the ready state or in the intermediate state of two coroutine switches, the _current_coctx of the current thread will be set to the scheduler COCTX;

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

[0090] As described above, the hook function of pthread_self actually returns the value of _current_coctx. In the program, by judging the type of the current COCTX, it is possible to know which type of thread and which running state it is in.

[0091] In this embodiment, the content stored in the COCTX structure includes: the coroutine stack and TLS. The running dynamic library allocates an independent stack for each coroutine, so it can completely simulate the behavior of a thread (including the memory size allocated in the stack and the call stack depth).

[0092] If the coroutine cannot completely simulate the TLS mechanism of the thread, it will cause the coroutine to be unable to safely access variables with TLS constraints. In this embodiment, the synchronization management module (hereinafter referred to as co_tls) realizes the encapsulation of TLS management, and the capabilities provided by co_tls are crucial for "transparent" simulation of threads. Taking Linux as an example, the following two types of TLS are stored in its TCB: dtv and specific.

[0093] The support of co_tls in this disclosure for specific: A data structure similar to specificarrays in the TCB needs to be maintained in co_tls. When a newly created coroutine is first swapped in for execution, the specific in the TCB of its affiliated scheduling thread will be copied. In addition, it is necessary to hook the library functions that manage specific. The Linux library functions are listed above, and there are similar functions in Windows, namely: TlsAlloc, TlsFree, TlsGetValue, and TlsSetValue.

[0094] Support of co_tls for dtv in the present disclosure: Similarly, when a newly created coroutine is first scheduled for execution, the dtv in the TCB also needs to be copied. However, different from specific, the content of specific in co_tls does not need to be synchronized with the TCB anymore; but because other dynamic libraries may be dynamically loaded during 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 a dynamic library is loaded. At the same time, we need to hook the library function calls for loading dynamic libraries (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 the link_map and the dtv incremental backup, the differences between the current coroutine and the dtv increment can be parsed. For the merging of the dtv increment, a "lazy" synchronization scheme is adopted, that is, it is judged whether the dtv needs to be synchronized when the coroutine is about to be swapped in. If dlopen is called in a certain coroutine, it is necessary to identify _current_coctx as the coroutine type in the hook of dlopen and immediately synchronize the dtv for the current coroutine.

[0095] In this embodiment, through the thread scheduling library function hook, a coroutine that is completely consistent with the thread capabilities can be simulated. The process of coroutine switching is as follows: First, in the initial state of the coroutine scheduling thread, _current_coctx is the scheduler COCTX; then, when a coroutine needs to be swapped in (resume), it is checked whether there are differences between the coroutine and the dtv incremental backup (if there are differences, synchronization is required). After completing the difference synchronization, _current_coctx is set to the context of the current coroutine; finally, when the coroutine requests to be swapped out, _current_coctx is restored to the scheduler COCTX again. The entire coroutine switching process is executed completely in the user space without any form of interaction with the operating system, thus maintaining the lightweight characteristics of the coroutine.

[0096] Optionally, the thread scheduling library function hook further includes: a lock library function hook. In the lock library function hook, the current running entity is judged through a global variable with thread-local constraints, and the corresponding lock mechanism for the current running entity is given based on the current running entity.

[0097] The dynamic runtime library provided in this embodiment can simulate thread creation and recycling with coroutine creation and recycling; meanwhile, it provides support for coroutine swapping in and out (i.e., simulation of thread suspension and wake-up) and proper handling of TLS (Thread Local Storage) (i.e., concurrent safe access to TLS among coroutines); moreover, based on the above capabilities, it provides support for coroutine locks and semaphores (mutex, rwlock, condition variables, semaphores, etc.), as well as timeout wake-up (timer) mechanisms. Therefore, whether it is thread management or thread suspension / wake-up (including: lock suspension, timer suspension, etc.) operations, there is no need to make any system calls and it is completely implemented in the user space. In the process of "transparently" replacing the runtime environment of the user-space application with a pure user-space environment, the solution provided by the optional implementation method of this embodiment ensures that the overall thread scheduling is "transparently" replaced with the user space.

[0098] In some optional implementation manners of this embodiment, as Figure 2 shown, the dynamic runtime library further includes: a memory management library function hook, which is a function related to memory management in the native library function constructed by 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.

[0099] Pure user-space memory management can be achieved by using the method of pre-allocating large chunks of memory through mmap (memory map).

[0100] Specifically, mmap can map a continuous memory address space with virtual addresses; moreover, as long as the starting address is aligned, it can be ensured that whether in the user mode or the kernel mode, the memory pages in their respective address spaces can be directly accessed through the starting address of the memory mapping (i.e., for the same page, the offset relative to the starting address is the same in both the user mode and the kernel mode). Therefore, when a user-mode program accesses the memory mapped by mmap, there is no difference from accessing general memory, and there is no need to explicitly use system calls to allocate physical memory. When an application program accesses a memory address for which no physical memory page has been allocated, a "page fault" will be implicitly triggered. The interrupt handler will allocate physical memory and establish a mapping relationship, and the application program itself will not enter the 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, returning to the state where the memory page is "missing" again; when this memory page is accessed next time, physical memory will be re-allocated for it through a page fault, or the page on the swap partition will be "swapped in" back to physical memory. To ensure that the memory page is always "in place" and at the same time reduce the number of page faults (the larger the page, the fewer the number of pages, and Linux generally uses 2MB huge pages), the "huge page" memory mapping method is often adopted in the pure user-mode programming framework to manage the memory mapping shared by the user mode and the kernel mode. The huge page memory will not be swapped out by the kernel, thus ensuring that its memory page is "anchored" to the corresponding physical memory page.

[0101] For the default memory allocator in traditional virtual machines, system calls are used to allocate small-sized memory, and mmap is only used to allocate large-sized memory. Therefore, it will still frequently enter the system call when allocating memory. The memory management subsystem in this system makes its memory implementation completely based on mmap to allocate large chunks of memory, achieving pure user-mode memory management. 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 memory management is "transparently" replaced with the user mode as a whole.

[0102] In some optional implementation methods of this embodiment, after the user-mode application starts and under 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, it wakes up the coroutines in the waiting queue corresponding to the IO operation library function hook.

[0103] The dynamic library provided in this embodiment can create a background thread - a monitoring thread for the context of the asynchronous IO model. Among them, the number of monitoring threads can be one or multiple. By creating multiple monitoring threads, load balancing of IO requests can be achieved. The background monitoring threads continuously poll the completion queue of the asynchronous IO model. When a new ready task is received, the coroutine context in the lock-free waiting queue is awakened, so as to wake up the coroutine that executes the corresponding task.

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

[0105] Through Figure 2 The runtime virtual machine system shown, the present invention proposes a "transparent" pure user-mode runtime virtual machine system. As long as the application program pre-loads the dynamic library at runtime, it can run in a pure user-mode virtualization environment without any modification to the application program, thereby improving application performance. That is, the present disclosure perfectly integrates the coroutine-based runtime virtual machine system and the pure user-mode programming technology, thereby providing a pure user-mode runtime environment that is completely "transparent" to the application program.

[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 construct a pure user-mode runtime environment that can bypass all system calls in most cases.

[0107] The solution of the present invention can provide perfect compatibility with the POSIX protocol interface. Developers can use the development library implemented based on the present invention to "transparently" implement the development of pure user-mode application programs. That is, the present disclosure provides a development interface that integrates the native network protocol stack and the file system ecosystem and is completely compatible with the POSIX protocol.

[0108] Further referring to Figure 3 , as an implementation of the runtime virtual machine system shown in the above figures during runtime, the present disclosure provides an embodiment of the system running method. As Figure 1 shows, a flow 300 of an embodiment of the system running method according to the present disclosure is shown. The system running 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 the user-mode application program to share the IO request memory queue with the kernel mode to achieve asynchronous drive 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-space application, the asynchronous model can be called when the user-space application runs.

[0112] In this embodiment, three types of library function calls can be implemented through the asynchronous IO model: setting the context of the asynchronous IO model; submitting and obtaining completed tasks; and enabling the registration of the kernel-user shared buffer through the memory mapping technology. Among them, the calls to submit and obtain the task completion status are directly interacted with the memory mapping queue in the user space and do not require system calls. Only the setting of the asynchronous IO context and the registration / unregistration of file descriptors need to be implemented as system calls.

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

[0114] In this embodiment, the dynamic runtime library is a type of dynamic library. When starting the user-space application, the dynamic runtime library is loaded to directly generate a runtime virtualization environment corresponding to the dynamic library, and the runtime virtualization environment is an environment that replaces the runtime environment of the user-space application.

[0115] In this embodiment, the compiled functions are stored in the dynamic runtime library. The dynamic runtime library provides an API (Application Program Interface) interface to the application program based on the library functions. The user-space application sends task requests to the dynamic runtime library by calling the API. Optionally, based on the native runtime library, the dynamic runtime library can be obtained by hooking the library functions related to thread scheduling in the native runtime library. After the dynamic runtime library is loaded, it can have scheduling capabilities equivalent to threads.

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

[0117] Step 303: In the runtime virtual environment, in response to detecting the call information of the native library functions of the user-space application by the user-space application, convert the IO operations of the operating system where the user-space application is located into operations processed by the asynchronous IO model through the IO operation library functions.

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

[0119] The system operation method provided by the embodiments of the present disclosure, first, load the library file of the asynchronous I / O model; second, load the dynamic runtime library when starting the user-mode application to generate a runtime virtualization environment; third, in the runtime virtual environment, in response to detecting the call information of the native library function of the user-mode application by the user-mode application, convert the I / O operation of the operating system where the user-mode application is located into being processed by the asynchronous I / O model through the I / O operation library function; finally, in the runtime virtual environment, monitor whether the I / O operation of the asynchronous I / O model is completed through the monitoring thread function, and when the I / O operation is completed, wake up the task waiting due to this I / O operation through the monitoring thread function. Thus, by combining the dynamic injection technology with the asynchronous I / O model, the encapsulation of system calls related to I / O operations in the runtime library is implemented using pure user-mode technology, and the original user-mode applications on the host run completely "transparently" in the pure user-mode runtime environment, so as to achieve higher performance without making any modifications to the application program, effectively control the occupancy rate of thread resources in the system, reduce system resource consumption and resource scheduling pressure, and thus improve the overall throughput and availability of the system.

[0120] Further refer to Figure 4 , as an implementation of the system operation method shown in the above figures, the present disclosure provides an embodiment of a system operation device. This device embodiment corresponds to Figure 3 the method embodiment shown, and this device can be specifically applied to various electronic devices.

[0121] As Figure 4As shown in the figure, 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. Among them, the above-mentioned file loading unit 401 can be configured to load the library file of the asynchronous IO model. The asynchronous IO model is used to share the IO request memory queue between the user-mode application and the kernel-mode to achieve asynchronous drive of physical devices. The above-mentioned library loading unit 402 can be configured to load the dynamic runtime library when starting the user-mode application to run, generate a runtime virtualization environment, and the runtime virtualization environment is an environment that replaces the runtime environment of the user-mode application. The above-mentioned conversion unit 403 can be configured to, when in the runtime virtual environment and detecting the call information of the native library function of the user-mode application by the user-mode application, convert the IO operation of the operating system where the user-mode application is located into being processed by the asynchronous IO model through the IO operation library function. The above-mentioned wake-up unit 404 can be configured to, 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 that is in the 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 by them can be respectively referred to Figure 1 Step 301, Step 302, and Step 303 in the corresponding embodiment.

[0123] The system operation device provided by the embodiments of the present disclosure, 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, generates a runtime virtualization environment, and the runtime virtualization environment is an environment that replaces the runtime environment of the user-mode application; third, the conversion unit 403, under the runtime virtual environment and detecting the call information of the native library function of the user-mode application by the user-mode application, converts the IO operation of the operating system where the user-mode application is located into an operation processed by the asynchronous IO model through the IO operation library function. Finally, the wake-up unit, under 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 in the waiting state due to the IO operation through the monitoring thread function. Thus, by combining the 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 run completely "transparently" in the pure user-mode runtime environment, so as to achieve higher performance without making any modifications to the application program, effectively control the thread resource occupancy rate in the system, reduce system resource consumption and resource scheduling pressure, and thus improve the overall throughput and availability of the system.

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

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

[0126] Generally, the following devices may 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 may allow the electronic device 500 to communicate with other devices wirelessly or wiredly to exchange data. Although Figure 5An electronic device 500 with various devices is shown, but it should be understood that it is not required to implement or have all the shown devices. Instead, more or fewer devices may be implemented or had. Figure 5 Each block shown in [it] may represent one device or, as needed, multiple devices.

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

[0128] It should be noted that the computer-readable medium in the embodiments of the present disclosure can be a computer-readable signal medium or a computer-readable storage medium or any combination of the two. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of the computer-readable storage medium can include, but are not limited to: an electrical connection with 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 of the above. In the embodiments of the present disclosure, the computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. And in the embodiments of the present disclosure, the computer-readable signal medium can include a data signal propagated in a baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The computer-readable signal medium can also be any computer-readable medium other than the computer-readable storage medium, and the computer-readable signal medium can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted by any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0129] The above computer-readable medium may be included in the server; or it may exist independently without being assembled into the server. The above computer-readable medium carries one or more programs, and when the one or more programs are executed by the server, the server is caused to: load a library file of an asynchronous I / O model, which is used to enable a user-space application to share an I / O request memory queue with the kernel space to achieve asynchronous drive of a physical device; when starting the execution of a user-space application, load a dynamic runtime library to generate a runtime virtualization environment, where the runtime virtualization environment is an environment that replaces the runtime environment of the user-space application; in the runtime virtual environment, in response to detecting hook call information of an I / O operation library function adapted to the asynchronous I / O model in the dynamic runtime library, convert the I / O operation of the operating system where the user-space application is located into an operation processed by the asynchronous I / O model through the I / O operation library function.

[0130] Computer program code for performing the operations of the embodiments of the present disclosure may be written in one or more programming languages or combinations thereof. The programming languages include object-oriented programming languages such as Java, Smalltalk, C++, and also include conventional procedural programming languages such as the "C" language or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, executed 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 the case of 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., by connecting through the Internet using an Internet service provider).

[0131] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code that contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, may be implemented by a dedicated hardware-based system for performing the specified functions or operations, or may be implemented by a combination of dedicated hardware and computer instructions.

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

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

Claims

1. A runtime virtual machine system, the system comprises: User-mode application programs; An asynchronous IO model for sharing an IO request memory queue between the user-mode application program and the kernel mode to achieve asynchronous driving of physical devices; A dynamic runtime library that can be loaded when the user-mode application program starts. After loading the dynamic runtime library, a runtime virtual environment is generated to replace the runtime environment of the user-mode application program; 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 functions of the user-mode application program. The IO operation library function is used to adapt the application program interface of the native library functions and the asynchronous IO model in the runtime virtual environment, and convert the IO operations of the operating system where the user-mode application program is located into those processed by the asynchronous IO model; The monitoring thread function is used to monitor whether the IO operations of the asynchronous IO model are completed in the runtime virtual environment, and wake up the tasks waiting due to the IO operations when the IO operations are completed.

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 / write hook function, and a POLL status 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 to the asynchronous IO model; The file descriptor management hook function is further used to unregister the file descriptor from the asynchronous IO model when the file descriptor is closed in the runtime virtual environment; The file descriptor read / 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.

3. The system according to claim 1, wherein, The dynamic runtime library uses coroutines to simulate the threads implemented in the native library functions. The IO operation library function hook includes: a file IO hook function and a file IO callback function, a network IO hook function and a network IO callback function; The file IO hook function is a function constructed using the HOOK mechanism and related to the file IO library functions in the native library functions; The network IO hook function is a function constructed using the HOOK mechanism and related to the network IO library functions in the native library functions. 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 IO operations in the runtime virtual environment. If it is a coroutine, the coroutine is suspended using the coroutine switching or suspension mechanism; The file I / O callback function is used to synchronize the I / O-related operations in the file I / O hook function with the asynchronous I / O model in the runtime virtual environment; The network I / O callback function is used to synchronize the I / O-related operations in the network I / O hook function with the asynchronous I / O model in the runtime virtual environment.

4. The system according to claim 1, the dynamic runtime library further comprises: A thread scheduling library function hook, which is a function related to thread creation, recycling, and suspension library functions in the native library function constructed by the HOOK mechanism. The thread creation, recycling, and suspension library functions are functions in the native runtime library of the application program 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 program runs, so as to schedule at least one coroutine through the coroutine scheduling thread.

5. The system according to claim 3, the dynamic runtime library further comprises: A memory management library function hook, which is a function related to memory management in the native library function constructed by 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 by memory allocation area, and the coroutines belonging to the same memory allocation area share the same coroutine scheduling thread cache.

6. The system according to any one of claims 3-5, the monitoring thread function creates a monitoring thread for each context in the asynchronous I / O model after the user-mode application starts and in the runtime virtual environment. The monitoring thread is used to poll the completion queue of the asynchronous I / O model, and when a new ready task is received in the completion queue, wake up the coroutines in the waiting queue corresponding to the I / O operation library function hook.

7. A system operation method, the method comprises: Loading the library file of the asynchronous I / O model, which is used to share the I / O request memory queue between the user-mode application and the kernel-mode to achieve asynchronous driving of physical devices; When starting the user-mode application to run, loading the dynamic runtime library to generate 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 call information of the native library function of the user-mode application by the user-mode application, converting the I / O operation of the operating system where the user-mode application is located into being processed by the asynchronous I / O model through the I / O operation library function; In the runtime virtual environment, monitoring whether the I / O operation of the asynchronous I / O model is completed through the monitoring thread function, and when the I / O operation is completed, waking up the tasks in the waiting state due to the I / O operation through the monitoring thread function.

8. A system operation device, the device comprises: A file loading unit, configured to load a library file of an asynchronous IO model, where the asynchronous IO model is used to enable a user-mode application to share an IO request memory queue with a kernel-mode to implement asynchronous driving of a physical device; A library loading unit, configured to load a dynamic runtime library when starting the user-mode application to run, and generate a runtime virtualization environment, where the runtime virtualization environment is an environment that replaces the runtime environment of the user-mode application; A conversion unit, configured to, in the runtime virtualization environment and when detecting call information of a native library function of the user-mode application, convert an IO operation of an operating system where the user-mode application is located into an operation processed by the asynchronous IO model through an IO operation library function; A wake-up unit, configured to, in the runtime virtualization environment, monitor whether an IO operation of the asynchronous IO model is completed through a monitoring thread function, and when the IO operation is completed, wake up a task in a 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 according to 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