Runtime virtual machine system and system operation method and device

Abstract

The invention provides a runtime virtual machine system. A specific embodiment of the system comprises a user mode application program; the asynchronous IO model is used for enabling the user mode application program and the kernel mode to share an IO request memory queue; a dynamic runtime library can be loaded when a user mode application program is started, and after the dynamic runtime library is loaded, a runtime virtual environment for replacing a runtime environment of the user mode application program is generated; the dynamic runtime library comprises an IO operation library function hook; the IO operation library function hook is constructed on the basis of a native library function of the user mode application program, and the IO operation library function is used for adapting to the application program of the native library function and the asynchronous IO model in the runtime virtual environment and converting IO operation of an operation system where the user mode application program is located into asynchronous IO model processing. According to the implementation mode, the transparent running environment of the application program can be replaced with the pure user mode environment, and IO operation of the pure user mode is achieved.

Description

Technical Field

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

[0002] 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 system calls of the host operating system to implement low-level IO operations. However, compared with user-mode code, the cost of executing system calls is extremely high. Summary of the invention

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

[0004] 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, 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 after loading the dynamic runtime library, a runtime virtual environment that replaces the runtime environment of the user-state application 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-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.

[0005] 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 a file descriptor table, and register the file descriptor in an asynchronous IO model; the file descriptor management hook function is also used to deregister the file descriptor from the asynchronous IO model in a runtime virtual environment and 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 a runtime virtual environment, and put the read request or the write request into a 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 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.

[0006] 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 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 IO operation to be completed in the runtime virtual environment. If it is a coroutine, the coroutine is suspending the coroutine using the 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.

[0007] In some embodiments, the above-mentioned dynamic runtime library also includes: a thread scheduling library function hook, which is a function related to thread creation, recycling and suspension library functions in native library functions 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.

[0008] 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 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 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 coroutine 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, 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, generating a runtime virtualization environment, the runtime virtualization environment being an environment that replaces the runtime environment of the user-mode application; in the runtime virtual environment, in response to detecting call information of a user-mode application to a native library function of the user-mode application, converting the IO operation of the operating system where the user-mode application is located into processing by the asynchronous IO model through an IO operation library function;

[0011] 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 in the waiting state due to the IO operation is awakened by 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, wherein the asynchronous IO model is used to enable user-mode applications and kernel-mode applications to share an IO request memory queue to achieve 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 under 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 under 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.

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

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

[0015] The runtime virtual machine system provided by the embodiment 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 after loading the dynamic runtime library, a runtime virtual environment that replaces the runtime environment of the user-state application 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-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 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 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, the user-state application has pure user-state IO capabilities without making any modifications to the application, saving labor costs and improving the convenience of user-state application operations. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

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

[0021] Figure 5 It is a schematic diagram of the structure of an electronic device suitable for implementing the embodiments of the present disclosure. DETAILED DESCRIPTION

[0022] The present disclosure is further described in detail below in conjunction with the accompanying drawings and embodiments. It is understood that the specific embodiments described herein are only used to explain the relevant invention, rather than to limit the invention. It is also necessary to explain that, for ease of description, only the parts related to the relevant invention are shown in the accompanying drawings.

[0023] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present disclosure may 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.

[0024] Runtime virtual machine systems are often used to provide cross-platform support or a virtualized operating environment, 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 uses its function hooks to overwrite the functions in the original application and the functions in the dynamic library linked to the original application.

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

[0026] Given 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 applications are connected, which is complex to implement, difficult to operate, and has high labor costs.

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

[0028] Dynamic library: also known as "dynamic link library", is a way to implement shared functions or objects in the operating system. Compiled functions are stored in dynamic libraries. Applications can dynamically load such library files and reference corresponding functions by function names; the same dynamic library can be loaded by different applications.

[0029] C runtime library: A general term for a type of dynamic link library that provides encapsulation of system calls and various operating system management interfaces, and provides a C-based programming interface for the interaction between applications and the operating system at runtime. Applications can be built directly based on the C runtime library, or run on a runtime virtual machine built based on the C runtime library (such as the Java virtual machine - JVM). In Linux-like systems, different distributions will 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.

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

[0031] Dynamic library injection: Reverse modification of a third-party application to make it execute the injected code is called "code injection"; dynamic library injection is a way to achieve code injection. The so-called "dynamic library injection" is to load the dynamic library into the application, inject the code in the dynamic library into the target application, 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 state and user state: To ensure the security of system operation, modern CPUs generally have several different instruction levels. At a high execution level, the code can execute privileged instructions and access any physical address. This operating level corresponds to the kernel state of the operating system. At a low execution level, the control scope of the code will be limited and can only move within the scope allowed by the corresponding level. This operating level corresponds to the user state. When a user state program needs to run functions provided by the operating system kernel, it can switch from user state to kernel state by executing the corresponding system call and run high execution level code in kernel state.

[0033] User-mode drivers: Device drivers usually run in kernel space, but with the continuous development of software and hardware technology, when trying to provide high concurrent server connection capabilities, the disadvantages of kernel-mode drivers began 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 (because kernel-mode errors will directly cause the system to crash), the steep learning curve for developers and the instability of the development interface (when the kernel version is upgraded, once the kernel driver interface changes, the driver needs to be re-adapted to the new version of the kernel), etc. Therefore, hardware companies such as Intel, Texas Instruments, and Freescale immediately began to study this problem 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 operating environments that define a kernel thread for each CPU core. In order to maximize network throughput, each kernel thread will be 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. 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.

[0035] Io_uring technology: a new asynchronous I / O model, io_uring is mainly designed to solve the problems of high system call and memory copy overhead, only supporting direct IO, and data size alignment restrictions. It uses memory mapping technology to create a shareable ring memory queue between user mode and kernel mode, and reduces system calls and memory copies through shared memory communication. Ideally, zero system call IO access can be achieved.

[0036] Coroutine: Also known as "fiber thread" or "micro" thread, a computer component that generates non-preemptive multitasking 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 (i.e. "yield"); and when the host thread calls the coroutine function again (i.e. "resume"), the coroutine will continue to execute from the previous yield point.

[0037] 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 (that is, thread local values). TLS is divided into two types and three situations according to the implementation method. The first type is a variable with a thread local constraint declared during coding, for example:

[0038] static__thread int global_tls_value=0;

[0039] The above variable declaration indicates a global integer variable with an initial value of 0. This variable can be accessed by all threads of the program in which it is located; however, changes to the variable value by different threads are only visible to this thread. The location of this type of TLS variable in the program data segment and its initial value can be determined during the compilation phase. Therefore, its related information and initial value will be stored in the compiled target program, and its position in the thread local context will be locked when the program is loaded. There is another situation, that is, when the program loads a dynamic library during operation, if there are TLS variables in the dynamic library, the location of these TLS in the thread local context must be dynamically determined 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, shows a schematic diagram of the structure of an embodiment of a runtime virtual machine system according to the present disclosure, the runtime virtual machine system 100 includes: a user state application 101, an asynchronous IO model 102 and a dynamic runtime library 103. The asynchronous IO model 102 is used to enable the user state application 101 and the kernel state to share the IO request memory queue to implement asynchronous driving of the physical device.

[0041] The dynamic runtime library 103 is loaded into the memory of the user-state application 101 when the user-state application is started. After loading the dynamic runtime library, 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 program interface and the asynchronous IO model 102 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.

[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 when the IO operation is completed, wake up the task that is in a waiting state due to the IO operation.

[0043] In this embodiment, the user state application 101 is an application running in the user state. The user state is a space for the application to run. Generally, all applications can only run in the user state. The native library function of the user state application is a function compiled in the native C runtime library of the user state 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 call of the host operating system multiple times, and the cost of the system call is relatively high.

[0044] In this embodiment, the dynamic runtime library 103 is loaded when the user-state application is running, and generates a runtime virtual environment that is different from the runtime environment of the user-state 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.

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

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

[0047] In this embodiment, the asynchronous IO model 102 can use io_uring, and io_uring also uses memory mapping technology to share IO cache between user state and kernel state. 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 directly driving 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 copy memory between the kernel.

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

[0049] 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 by program developers, device or file access can be based on file handles (that is, a system equivalent to the kernel protocol stack and kernel file system is implemented in user mode). The specific code development process will not be repeated 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 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.

[0051] The runtime virtual machine system provided by the embodiment 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 of 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 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, the user-state application has pure user-state IO capabilities without making any modifications to the application, which saves labor costs and improves the convenience of user-state application operations.

[0052] In some optional implementations of the present disclosure, 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.

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

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

[0055] The above 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 a submission queue of an 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 state 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 the user state, further reducing system calls and improving IO performance; compared with the POLL state function in the native library function, the POLL state hook function can put the POLL wait request or the POLL wake-up request into the submission queue of the asynchronous IO model, further reducing system calls and improving IO performance.

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

[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 IO operation to complete in the runtime virtual environment. If it is a coroutine, the coroutine is suspended using the coroutine switching or suspension mechanism.

[0059] The above-mentioned file IO hook function is constructed by using the HOOK mechanism and is 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 a thread state. If it is a thread, it will call the native system call or library function; if it is a coroutine, it is necessary to use the logic of the file IO hook function itself.

[0060] The network IO hook function is a function built with the HOOK mechanism and related to the network 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 network IO library function in the native library function 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 (calling socket or accept), the network IO hook function adds the newly created socket file descriptor to the 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).

[0061] 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 yield / resume.

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

[0063] Similarly, when the coroutine calls library functions such as poll to try to wait for certain sockets to be ready, the network IO hook function will check the UrFd table to see if any of these sockets are already in the ready state. If yes, it will return immediately; if not, it will mark the IO waiting state of the current coroutine context on all sockets monitored by this poll operation and yield.

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

[0065] There is a hook function for generating a coroutine scheduling thread in the dynamic runtime library. After the coroutine scheduling thread is generated, each coroutine scheduling thread maintains a lock-free wakeup queue (wakeup queue); the above-mentioned waking up a coroutine means: putting the coroutine context of this coroutine into the wakeup queue of the scheduling thread to which it belongs.

[0066] 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 state of the file; 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.

[0067] 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 the file descriptor read, 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 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 environment file descriptor, wherein the waiting queue of the file descriptor is a lock-free queue structure that supports waiting with timeout / without timeout, and simultaneously supports coroutine swapping and thread suspension.

[0068] The file IO callback function also includes: a second callback function related to file descriptor writing, which is used to submit the write request related to the file descriptor to the submission queue of the asynchronous IO 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 using the yield (or thread suspension) method to give 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 surrounded.

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

[0070] 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. Among them, the second callback function is started when the file descriptor is created or closed, and a UrFd structure is created for the newly created file descriptor, and is put into the UrFd table, and the file descriptor is registered in the asynchronous IO model; when the file descriptor is closed, the file descriptor is deregistered from the asynchronous IO model, and the UrFd structure in the UrFd table is released.

[0071] When the POLL state is not ready, the third callback function submits the POLL state request to the submission queue of the asynchronous IO model, puts the current coroutine context into the waiting queue of UrFd, and uses yield (or thread suspension) to give up. The waiting operation with timeout is implemented through a lock-free timeout queue.

[0072] 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 function of file IO hook function through file IO callback function and realizes docking with asynchronous IO model, takes over the network IO hook function through network IO callback function and realizes docking with asynchronous IO model, increases the user state effect of the runtime environment of the runtime virtual machine system, reduces system calls, and improves IO performance.

[0073] In some optional implementations of this embodiment, such as Figure 2As shown, the dynamic runtime library also includes: a thread scheduling library function hook. The thread scheduling library function hook is a function related to thread creation, recycling and suspension library functions in native library functions built 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, a coroutine scheduling thread is generated to schedule at least one coroutine through the coroutine scheduling thread.

[0074] In this embodiment, a dynamic runtime library is loaded when a user-mode application is started, 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, and the specific steps of the coroutine scheduling thread scheduling at least one coroutine include: the scheduler obtains a coroutine in a ready state from the lock-free queue in at least one coroutine; synchronizes the coroutine context of the coroutine with the thread context in the thread control block; after the coroutine actively gives up, the scheduler obtains the next coroutine in a 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 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.

[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" (TCB), which is the context structure of the thread. dtv and specific array are the data structures that store TLS data in TCB. dtv: used to store TLS variables defined in the encoding phase. This data will be incremented as the application loads a new dynamic library, because there may also be TLS variables in the dynamic library.

[0077] specific: Dynamically created TLS (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 set of pointer arrays (specific arrays), so there is an upper limit on the number (Linux supports the creation of up to 1024 dynamic TLS).

[0078] In this embodiment, the scheduler performs 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 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.

[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 its role is similar to that of a 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:

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

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

[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, which is declared 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 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 if two coroutines are in the intermediate state of switching, the _current_coctx of the current thread 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 hook function of pthread_self actually returns the value of _current_coctx. In the program, by judging the type of the current COCTX, you can know which thread and running state it is currently in.

[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 the coroutine cannot fully simulate the TLS mechanism of the thread, the coroutine will not be able to safely access variables with TLS constraints. In this embodiment, the encapsulation of TLS management is implemented through the synchronization management module (hereinafter referred to as co_tls). The capabilities provided by co_tls are crucial for "transparent" simulation of threads. Taking Linux as an example, its TCB stores the following two types of TLS: dtv and specific.

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

[0094] The co_tls disclosed in the present 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 does not need to be synchronized with the TCB; but since 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 scheduler COCTX to describe the incremental part of dtv generated each time a dynamic library is loaded. At the same time, we need to hook the library function call that loads the dynamic library (the 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. Combined with 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 scheme 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, you need 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 a thread scheduling library function hook. The switching process of the coroutine is as follows: First, in the initial state of the coroutine scheduling thread, _current_coctx is schedulerCOCTX; 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 swapping out, _current_coctx is restored to scheduler COCTX. The entire coroutine switching process is executed completely in user mode, without 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 based on the current running subject, a corresponding lock mechanism is given to 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 in and out (i.e., simulation of 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 it is completely implemented 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 is adopted to ensure that the overall thread scheduling is "transparently" replaced with the user mode.

[0098] In some optional implementations of this embodiment, such as Figure 2 As shown, the dynamic runtime library also includes: a memory management library function hook. The memory management library function hook is a function related to memory management in the native library function and is 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.

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

[0100] Specifically, mmap can map a section of memory address space with continuous virtual addresses; and as long as the starting address is aligned, it can be achieved that both in user mode and kernel mode, the memory pages in their respective address spaces can be directly accessed through the starting address of the memory mapping (that is, the offset of the same page relative to the starting address is the same in user mode and kernel mode). Therefore, when a user-mode program accesses the memory mapped by mmap, it is no different from general memory access, and there is no need to explicitly use system calls to allocate physical memory. When an application accesses a memory address that has not yet been allocated a physical memory page, a "page fault" will be implicitly triggered, and the interrupt handler will allocate physical memory and establish a mapping relationship, and the application itself will not fall into kernel mode. However, the physical memory allocated by the page fault interrupt mechanism may be released or swapped out to the swap partition by the kernel due to insufficient available physical memory, and the memory page will return to the "missing" state again; the next time this memory page is accessed, physical memory will be reallocated to it through a page fault interrupt, or the page on the swap partition will be "swapped" back into physical memory. In order to ensure that the memory page is always "in place" and reduce the number of page fault interrupts (the larger the page, the fewer pages there are, Linux generally uses 2MB huge pages), pure user-mode programming frameworks often use "huge page" memory mapping to manage the memory mapping shared by user mode and kernel mode. 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] The default memory allocator in the traditional virtual machine uses system calls to implement when allocating small-sized memory, and only uses mmap when allocating large-sized memory. Therefore, it will often fall into the situation of system calls when allocating memory. The memory management subsystem in this system enables its memory implementation to allocate large blocks of memory completely based on mmap, realizing pure user-mode memory management. In the process of "transparently" replacing the runtime environment of the user-mode application with the pure user-mode environment, the solution provided by the optional implementation method of this embodiment is adopted to ensure that the overall memory management is "transparently" replaced with the user-mode.

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

[0103] The dynamic runtime provided in this embodiment can create a background thread - monitoring thread for the context of the asynchronous IO model, wherein the monitoring thread can be one or more monitoring threads. By creating multiple monitoring threads, IO request load balancing can be achieved. The background monitoring thread repeatedly polls 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 to achieve the purpose of awakening the coroutine that executes 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] pass Figure 2 The runtime virtual machine system shown in the figure, the present invention proposes a "transparent" pure user-mode runtime virtual machine system, the application program can run in a pure user-mode virtualization environment without any modification to the application program by pre-loading a dynamic library at runtime, thereby improving the application performance; that is, the present disclosure perfectly integrates the coroutine runtime virtual machine system with 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 operating 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, and developers can use the development library based on the present invention to "transparently" develop pure user-mode applications. That is, the present invention provides a development interface that integrates the native network protocol stack and the file system ecosystem and is fully compatible with the POSIX protocol.

[0108] Further references Figure 3 As an implementation of the runtime virtual machine system shown in the above figures, the present disclosure provides an embodiment of the system operation method. Figure 1 , shows a process 300 of an embodiment of a system operation method according to the present disclosure, the system operation method comprises the following steps:

[0109] Step 301, loading 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 and the kernel-mode application to share an IO request memory queue, so as to implement asynchronous driving of the physical device.

[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, three 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 registering the kernel user shared buffer through memory mapping technology. Among them, the calls for submitting and obtaining the task completion status are all directly interacting with the memory mapping queue in the user state, and no system call is required. Only the asynchronous IO context setting and the registration / unregistration of the file descriptor need to be implemented as a system call.

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

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

[0115] In this embodiment, the compiled functions are stored in the dynamic runtime library, and the dynamic runtime library provides an API (Application Program Interface) interface to the application based on the library function, and the user-mode application sends a task request 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, and after the dynamic runtime library is loaded, it can have a scheduling capability equivalent to that of a thread.

[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 under 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 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 state application to the native library function of the user state application, the IO operation of the operating system where the user state 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 by monitoring the thread function, and when the IO operation is completed, wake up the task in the waiting state due to the IO operation by monitoring the thread function.

[0119] The system operation method provided by the embodiment of the present disclosure firstly 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 into processing 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 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 the system call related to the IO operation in the runtime library is changed to the pure user-mode technology, and the original user-mode application on the host machine is completely "transparently" running 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 the system resource consumption and resource scheduling pressure, and thus improving the overall throughput and availability of the system.

[0120] Further references 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, which is similar to Figure 3 Corresponding to the method embodiment shown, the device can be specifically applied to various electronic devices.

[0121] like Figure 4As shown, 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, and the asynchronous IO model is used to share the IO request memory queue between the user-mode application and the kernel mode to realize the asynchronous drive of the physical device. The above-mentioned library loading unit 402 can be configured to load the dynamic runtime library when starting the user-mode application to run, and generate a runtime virtualization environment. 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 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 call information of the native library function of the user-mode application under the runtime virtual environment. The above-mentioned wake-up unit 404 can be configured to monitor whether the IO operation of the asynchronous IO model is completed through the monitoring thread function under 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.

[0122] In the present embodiment, the specific processing of the file loading unit 401, the library loading unit 402, and the conversion unit 403 and the technical effects thereof can be referred to in Figure 1 Corresponding to step 301, step 302, and step 303 in the embodiment.

[0123] The system operation device provided by the embodiment of the present disclosure, first, the file loading unit 401 loads the library file of the asynchronous IO model; secondly, the library loading unit 402 loads the dynamic runtime library when starting the user-mode application to generate a runtime virtualization environment, and the runtime virtualization environment is an environment that replaces the runtime environment of the user-mode application; from then on, the conversion unit 403 detects the call information of the user-mode application to the native library function of the user-mode application under 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 awakening unit monitors whether the IO operation of the asynchronous IO model is completed through the monitoring thread function under 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-state technology, and the original user-state applications on the host machine run completely "transparently" in a pure user-state 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] Reference below Figure 5 , which shows a structural schematic diagram of an electronic device 500 suitable for implementing an embodiment of the present disclosure.

[0125] like Figure 5 As shown, 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. 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 via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0126] Typically, the following devices may be connected to the I / O interface 505: an input device 506 including, for example, a touch screen, a touch pad, 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 by wire to exchange data. Figure 5The electronic device 500 is shown with various devices, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead. Figure 5 Each block shown in the figure may represent one device, or may represent multiple devices as required.

[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 a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device 509, or installed from a storage device 508, or installed from a 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 executed.

[0128] It should be noted that the computer-readable medium of the embodiment of the present disclosure may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may 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 embodiment of the present disclosure, the computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, device or device. In the embodiment of the present disclosure, the computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which a computer-readable program code is carried. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The computer readable signal medium may also be any computer readable medium other than a computer readable storage medium, which may 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 may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0129] The computer-readable medium may be included in the server; or it 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, the asynchronous IO model is used to share the IO request memory queue between the user-mode application and the kernel mode to realize asynchronous driving of the physical device; when starting the user-mode application to run, loads the dynamic runtime library and generates a runtime virtualization environment, 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 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 a user's computer, partially on a user's computer, as a separate software package, partially on a 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 via 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., via the Internet using an Internet service provider).

[0131] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the 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 from the order 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 flow chart, and the combination of the boxes in the block diagram and / or flow chart 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 may be implemented by software or by hardware. The described units may also be arranged in a processor, for example, may be described as: a processor including a file loading unit, a library loading unit, and a conversion unit. The names of these units do not constitute a limitation on the units themselves in certain cases, for example, the file loading unit may also be described as a unit "configured to load a library file of an asynchronous IO model".

[0133] The above description is only a preferred embodiment of the present disclosure and an explanation of the technical principles used. 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 cover other technical solutions formed by any combination of the above-mentioned technical features or their equivalent features without departing from the above-mentioned inventive concept. For example, the above-mentioned features are replaced with the technical features with similar functions disclosed in the embodiments of the present disclosure (but not limited to) to form a technical solution.

Claims

1. A runtime virtual machine system, the system comprising: User-mode applications; An asynchronous IO model is used to enable the user-mode application and the kernel-mode to share an IO request memory queue to implement asynchronous driving of a physical device; A dynamic runtime library that can be loaded when the user-mode application is started, after loading the dynamic runtime library, generates a runtime virtual environment that replaces the runtime environment of the user-mode application; 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 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 under 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 under the runtime virtual environment, and put the read request or the write request into 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 using a HOOK mechanism and 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 a 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 the 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: A file loading unit is configured to load 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; 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