Runtime virtualization method and device and runtime virtual machine system

Abstract

The invention provides a runtime virtualization method and device. A specific implementation mode of the method comprises the steps that a dynamic runtime library is constructed based on a native runtime library of an application program, and the dynamic runtime library simulates threads achieved in the native runtime library in a coroutine mode; when the application program is started, the dynamic runtime library is loaded, a runtime virtualization environment and a coroutine scheduling thread running in the runtime virtualization environment are generated, the coroutine scheduling thread is used for scheduling a coroutine, and the runtime virtualization environment is an environment after the runtime environment generated by the original runtime library is replaced; the method comprises the following steps: receiving a task request of an application program in a runtime virtualization environment; and based on the task request and the dynamic runtime library, adopting a coroutine scheduling thread to schedule a coroutine, so that the coroutine completes a task corresponding to the task request. According to the embodiment, on the premise that the application program in the target operating system does not need to be modified or recompiled, the concurrency performance of the application program is improved, and resource consumption and resource scheduling pressure are reduced.

Description

Technical Field

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

[0002] A coroutine is a lightweight parallel subroutine that reuses the runtime slice of a host thread. Since a coroutine reuses the context of a host thread, the swapping in and out of a coroutine is equivalent to only one function call, eliminating the extra context switching cost. Compared to ordinary threads, the cost of swapping in and out a coroutine is generally about an order of magnitude lower.

[0003] As a runtime virtualization solution, the coroutine library reduces the overhead of high-concurrency applications and improves performance by utilizing lightweight switching of coroutines. However, its implementation often only simulates the non-blocking asynchronous nature of IO library functions for coroutines, and does not properly resolve the compatibility issues between coroutines and threads. Summary of the invention

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

[0005] In a first aspect, an embodiment of the present disclosure provides a runtime virtualization method, the method comprising: constructing a dynamic runtime library based on a native runtime library of an application, the dynamic runtime library simulating threads implemented in the native runtime library in a coroutine manner; loading the dynamic runtime library when starting the application, generating a runtime virtualization environment and a coroutine scheduling thread running in the runtime virtualization environment, the coroutine scheduling thread being used to schedule at least one coroutine, the runtime virtualization environment being an environment after replacing the runtime environment generated by the native runtime library; receiving a task request from the application in the runtime virtualization environment; and scheduling the coroutine using the coroutine scheduling thread based on the task request and the dynamic runtime library, so that the coroutine completes the task corresponding to the task request.

[0006] In some embodiments, the above-mentioned method of scheduling a coroutine based on a task request and a dynamic runtime library using a coroutine scheduling thread so that the coroutine completes the task corresponding to the task request includes: creating at least one coroutine based on the task request and the dynamic runtime library; sending at least one coroutine to a coroutine scheduling thread so as to schedule at least one coroutine using a coroutine scheduling thread.

[0007] In some embodiments, the above-mentioned coroutine scheduling thread includes: a scheduler and a lock-free queue for placing at least one coroutine, and scheduling at least one coroutine using the coroutine scheduling thread includes: 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.

[0008] In some embodiments, the above method also includes: receiving a native request from an application, creating at least one thread based on the native request and a native runtime library in a dynamic runtime library, and executing a task corresponding to the native request through the at least one thread.

[0009] In some embodiments, the above-mentioned application-based native runtime library builds a dynamic runtime library, including: using a hook mechanism to build a thread library function hook related to the first library function, the first library function is a library function in the native runtime library that creates a thread and obtains a thread descriptor; in the thread 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 a thread local constraint, and the thread local storage information in the coroutine context structure is managed by a synchronization management module, and the synchronization management module is used to synchronize the thread local storage of the coroutine when the coroutine scheduling thread schedules the coroutine.

[0010] In some embodiments, the above-mentioned native runtime library based on the application program, building a dynamic runtime library also includes: using a hook mechanism to build a lock library function hook related to the second library function, the second library function is a library function in the native runtime library that is respectively related to locks, conditional variables, and semaphores; in the lock library function hook, the current running subject is judged through global variables, and based on the current running subject, a corresponding lock mechanism is given to the current running subject.

[0011] In some embodiments, the above-mentioned application-based native runtime library, building a dynamic runtime library also includes: using a hook mechanism to build a switching library function hook related to a third library function, the third library function is a library function in the native runtime library that can cause a thread switching or suspension operation; the switching library function hook is used to use a coroutine switching or suspension mechanism instead of a thread switching or suspension mechanism.

[0012] In the second aspect, an embodiment of the present disclosure provides a runtime virtualization device, which includes: a construction unit, configured to construct a dynamic runtime library based on the native runtime library of the application, and the dynamic runtime library simulates the threads implemented in the native runtime library in a coroutine manner; a generation unit, configured to load the dynamic runtime library when starting the application, generate a runtime virtualization environment and a coroutine scheduling thread running in the runtime virtualization environment, the coroutine scheduling thread is used to schedule at least one coroutine, and the runtime virtualization environment is an environment after replacing the runtime environment generated by the native runtime library; a task receiving unit, configured to receive a task request of the application in the runtime virtualization environment; a coroutine scheduling unit, configured to schedule the coroutine using the coroutine scheduling thread based on the task request and the dynamic runtime library, so that the coroutine completes the task corresponding to the task request.

[0013] In some embodiments, the scheduling unit is configured to: create at least one coroutine based on the task request and the dynamic runtime library; send at least one coroutine to the coroutine scheduling thread to schedule the at least one coroutine using the coroutine scheduling thread.

[0014] In some embodiments, the above-mentioned coroutine scheduling thread includes: a scheduler and a lock-free queue for placing at least one coroutine, and the scheduling unit is further configured as: 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.

[0015] In some embodiments, the above-mentioned device also includes: a native receiving unit, configured to receive a native request of an application; a thread scheduling unit, configured to create at least one thread based on the native request and the dynamic runtime library, and execute the task corresponding to the native request through the at least one thread.

[0016] In some embodiments, the above-mentioned construction unit is configured to: use a hook mechanism to construct a thread library function hook related to the first library function, and the first library function is a library function in the native runtime library that creates a thread and obtains a thread descriptor; in the thread 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 a thread local constraint, and the thread local storage information in the coroutine context structure is managed by a 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.

[0017] In some embodiments, the above-mentioned construction unit is configured to: use a hook mechanism to construct a lock library function hook related to the second library function, and the second library function is a library function related to the lock in the native runtime library; in the lock library function hook, through a global variable with a thread-local constraint, the current running subject is judged, and based on the current running subject, a corresponding lock mechanism is given to the current running subject.

[0018] In some embodiments, the above-mentioned construction unit is configured to: use a hook mechanism to construct a switching library function hook related to a third library function, where the third library function is a library function in the native runtime library that can cause a thread switching or suspension operation; the switching library function hook is used to use a coroutine switching or suspension mechanism instead of a thread switching or suspension mechanism.

[0019] In the third aspect, an embodiment of the present disclosure provides a runtime virtual machine system, the system comprising: a coroutine scheduling thread, a main thread, an event-driven (EPOLL) thread, and an asynchronous input and output (AIO) and timer thread running in a runtime virtualization environment, wherein the runtime virtualization environment is generated by loading a dynamic runtime library, and the dynamic runtime library is constructed based on the native runtime library of the application, and the dynamic runtime library simulates the threads implemented in the native runtime library in a coroutine manner; the coroutine scheduling thread is used to schedule at least one coroutine so that the coroutine completes the task request of the application; the main thread is created when the application starts; the event-driven thread is used to maintain the status of the file handle, and wake up the corresponding coroutine when the read or write cache is ready and there is a read and write task blocked on the file handle; the asynchronous input and output and timer threads obtain the asynchronous input and output task results and wake up the coroutine in IO waiting; when the system call times out and returns, the task that has exhausted the timeout is popped up and woke up; when the system calls the asynchronous IO task result, wake up the coroutine in IO waiting.

[0020] 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 first aspect.

[0021] 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 first aspect.

[0022] The runtime virtualization method and device provided by the embodiment of the present disclosure firstly build a dynamic runtime library based on the native runtime library of the application; secondly, load the dynamic runtime library when starting the application, generate a runtime virtualization environment and a coroutine scheduling thread running in the runtime virtualization environment, the coroutine scheduling thread is used to schedule at least one coroutine, and the runtime virtualization environment is the environment after replacing the runtime environment generated by the native runtime library; thirdly, receive the task request of the application in the runtime virtualization environment; finally, based on the task request and the dynamic runtime library, use the coroutine scheduling thread to schedule the coroutine so that the coroutine completes the task corresponding to the task request. Therefore, the present disclosure generates a runtime virtualization environment through a dynamic runtime library, transparently replaces the runtime environment of the application, and improves the concurrent performance of the application without any modification or recompilation of the application; the thread-capable coroutine generated by the dynamic runtime library supports lightweight coroutine scheduling, which can 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. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] 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:

[0024] Figure 1 is a flow chart of one embodiment of a runtime virtualization method according to the present disclosure;

[0025] Figure 2 is a structural diagram of an embodiment of a runtime virtualization device according to the present disclosure;

[0026] Figure 3 is a structural diagram of a runtime virtual machine system according to the present disclosure;

[0027] Figure 4 is another structural diagram of a runtime virtual machine system according to the present disclosure;

[0028] 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

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

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

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

[0032] Among the solutions of this type that have been made public, libhybris based on Android bionic is a typical example. Android dynamic libraries are all compiled based on bionic, but there is no bionic runtime environment in the GNU version of Linux distribution. In order to run Android dynamic libraries in the GNU distribution system, a runtime virtual machine compatible with glibc is required, that is, the libhybris library loads the Android dynamic library based on the glibc system, and uses the hook function in libhybris to overwrite the bionic library function; and the hook function of libhybris simulates the similar implementation in the bionic library function by dynamically loading and calling the corresponding function in glibc. In other words, libhybris solves the compatibility problem of the two C runtime libraries and realizes a runtime environment for running Android programs across platforms.

[0033] Libhybris can be regarded as a complete runtime virtual machine, which implements a complete set of bionic simulation runtime environment in the GNU environment. In addition, many coroutine libraries also implement some C runtime library hooks to solve the asynchronous problems of coroutine lock waiting and IO waiting, such as the open source libco library, libgo library, etc.

[0034] A complete coroutine library will hook those IO library functions that require blocking waiting (IO may not be completed immediately, so the corresponding library function call needs to wait for the IO operation to end before returning), as well as coroutine-specific locks.

[0035] Why does a coroutine need to hook an IO library function? Because the running of a coroutine depends on its host thread. Once the coroutine tries to call a library function that may cause a blocking wait, the host thread will be suspended during the waiting process until the function returns. During this suspension phase, the host thread cannot execute any other code.

[0036] Coroutines are scheduled by time-sharing the host thread's time slices, and their performance depends on the effective utilization of the host thread's time slices. Once a host thread is suspended by a coroutine, and other coroutines cannot be called during this period, the time slice of the suspension phase will be wasted, resulting in a decrease in overall performance. Coroutines suspending host threads will not only affect performance, but also cause a scheduling "deadlock" problem. Imagine a situation where all host threads are stuck in a long-term suspension wait, and at this time there is a new coroutine that wants to be scheduled for execution, then the system falls into a state similar to "deadlock", and the new coroutine can only wait for one of the host threads to return from the suspended library function. Once the new coroutine has a certain "timeout" mechanism, the extreme situation of the new coroutine always timing out and failing may occur. In addition, if the coroutine uses "thread locks", it will aggravate the "scheduling deadlock". If coroutine 1 is swapped out (yield) while holding thread lock A, and coroutine 2, which is swapped in (resume) by the current host thread, also needs to lock thread lock A, then coroutine 2 will suspend the host thread and wait for thread lock A to be released; but since the host thread is suspended, it will never have the opportunity to swap in coroutine 1 that can unlock thread lock A, resulting in a complete deadlock.

[0037] A complete coroutine library needs to simulate all library functions that may cause blocking waits (including IO waits and lock waits) with non-blocking asynchronous calls. In other words, when a coroutine may fall into IO waits or lock waits, it should use the yield mechanism to return to the host thread so that the host thread can continue to call other coroutines; later, when the coroutine that was previously swapped out due to waiting can continue to execute (that is, the resources it is waiting for are ready - such as IO completion, unlocking, etc.), it can be scheduled (resume) again in the subsequent idle time slice of the host thread. The IO library function hook provided by the C runtime library in the coroutine library is a relatively perfect solution. For example, when an application using the coroutine library calls the recv function to receive a network packet, it actually calls the recv function hooked by the coroutine library; if the network packet has not arrived at this time, the hook function will be swapped out with the yield mechanism; later, when the network packet arrives, the previously swapped out coroutine will be resumed again at a suitable time, and continue to execute from the previously swapped out position, complete the network packet reception and return from the hook function. In this way, when developing applications, you can directly use the functions in the C runtime library; until runtime, the native library functions are dynamically replaced with the coroutine version of the hook function through dynamic library injection. In this way, through the above solution, the application is almost "transparent" coroutine.

[0038] An application may have both coroutines and threads. The waiting of coroutine locks is simulated by yield behavior, while waiting of thread locks requires the thread to be suspended. The two behavior patterns are often incompatible. Therefore, if an application using the coroutine library wants to introduce a lock mechanism, it needs to carefully choose whether to use coroutine locks or thread locks, which means that it cannot be completely "transparent" to the application.

[0039] Furthermore, existing coroutine libraries generally do not properly handle the cross-coroutine security issues of thread local storage. In other words, coroutines scheduled by the same host thread will share the thread local storage of the host thread, which will cause each other to "contaminate" the thread local storage, making it impossible to achieve cross-coroutine secure access to thread local storage, and thus not having the equivalent capabilities of threads.

[0040] In summary, most coroutine libraries are not complete runtime virtual machines, but only use dynamic library injection to hook some C runtime library functions to solve concurrent performance problems and scheduling deadlock problems. In other words, coroutine libraries are generally just a runtime virtualization solution for threads (using coroutines to simulate threads), and will not fully simulate the underlying interface in the C runtime library.

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

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

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

[0044] 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, aiming to provide a cross-platform program runtime environment (such as the "JAVA virtual machine", which shields the differences between the C runtime libraries of different operating systems and provides system-independent development interfaces and runtime environments); or provide a virtualized runtime environment for the target operating system (such as a "container", which can run multiple container systems simultaneously in a host system). Compared to a "virtual machine", a runtime virtual machine does not completely simulate a virtual host, but only provides a runtime environment, and is therefore more lightweight.

[0045] 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 (the latter is also called a code "hook").

[0046] 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 (i.e. the so-called "same location" in the previous article).

[0047] 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:

[0048] static__thread int global_tls_value=0;

[0049] The variable declaration above indicates a global integer variable with an initial value of 0. This variable can be accessed by all threads of the program, but changes to the variable value by different threads are only visible to the current thread. The location of this type of TLS variable (called "dtv" in glibc) 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 location 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. Different operating systems provide similar APIs to provide support for this type of TLS.

[0050] The present disclosure provides a runtime virtualization method that can flexibly use coroutines to implement thread simulation and scheduling, thereby improving concurrency performance. Figure 1 , shows a process 100 of an embodiment of a runtime virtualization method according to the present disclosure, the runtime virtualization method comprising the following steps:

[0051] Step 101: Build a dynamic runtime library based on the native runtime library of the application.

[0052] In this embodiment, the native runtime library is a runtime library that supports the running of the application program and provides a programming interface for the interaction between the application program and the operating system during the running time. The native runtime library may be constructed based on the C language.

[0053] In this embodiment, the dynamic runtime is a dynamic library, and the compiled functions are stored in the dynamic runtime. The dynamic runtime provides an API (Application Program Interface) interface to the application program to support task requests. The API interface is a library function of the dynamic runtime. When the dynamic runtime is not loaded, the application program needs to call the API of the native runtime (the library function of the native runtime). After the dynamic runtime is loaded, the API of the native runtime is hijacked by the library function of the dynamic runtime. Therefore, when the application has a task requirement, the API of the dynamic runtime is actually called, and a task request is sent to the API of the dynamic runtime. On the basis of the native runtime, the dynamic runtime can be obtained by hooking the library functions related to thread scheduling in the native runtime, and the obtained dynamic runtime can have a scheduling capability equivalent to that of a thread after being loaded.

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

[0055] Step 102, loading the dynamic runtime library when starting the application, generating a runtime virtualization environment and a coroutine scheduling thread running in the runtime virtualization environment.

[0056] In this embodiment, the coroutine scheduling thread is used to schedule at least one coroutine, and the runtime virtualization environment is an environment after replacing the runtime environment generated by the native runtime library.

[0057] In this embodiment, loading the dynamic runtime library means dynamically injecting the dynamic runtime library into the application when the operating system starts the application, and the runtime injection of the dynamic runtime library means loading a certain dynamic library into the operating system before starting an application and loading the program into the memory, and running the initialization code in the dynamic library. Through this program loading method, the pre-loaded dynamic library has the opportunity to build a runtime virtualization environment in advance, and the runtime virtualization environment can replace the runtime environment generated by the native runtime library. In the runtime virtualization environment, the application or operating system can call the function in the dynamic runtime library in real time. In this embodiment, after the application is started, the coroutine scheduling thread can be started accordingly.

[0058] In this embodiment, by loading the dynamic runtime library, a runtime virtualization environment can be implemented without making any modifications to the application (neither the application code needs to be changed nor the application needs to be recompiled). At this time, the application runs in the runtime virtualization environment without any perception (in this runtime virtualization environment, when the application needs to call the library function of the native runtime library, the library function of the dynamic runtime library is actually called). The runtime virtualization method provided by the present disclosure not only improves performance and reduces resource consumption, but also enables applications developed based on the native runtime library to obtain performance improvements and reduce resource consumption without modification or perception.

[0059] In this embodiment, the coroutine scheduling thread is a thread that schedules coroutines. The coroutine scheduling thread can be one or more. The number of coroutine scheduling threads can be determined based on the number of cores. For example, for an operating system with 64 cores, the number of coroutine scheduling threads is 64.

[0060] Optionally, the coroutine in this embodiment may have capabilities comparable to those of a thread, and the coroutine may also completely simulate the behavior of a thread, and for this reason, the coroutine scheduling thread may also be considered as a thread that schedules a thread.

[0061] Step 103: receiving a task request of an application program in a runtime virtualization environment.

[0062] In this embodiment, the task request of the application program may correspond to one or more tasks. For each different task, the application program may establish a corresponding thread or coroutine by calling a function in the dynamic runtime library. Each thread executes a corresponding task, and each coroutine executes a corresponding task.

[0063] In this embodiment, the application is a program developed based on a native runtime library. Under the premise that the application is not modified or perceived, the application is made to run unconsciously in a runtime virtualization environment, and the application calls library functions in the dynamic runtime library to implement corresponding functions.

[0064] Step 104 , based on the task request and the dynamic runtime library, the coroutine is scheduled using a coroutine scheduling thread so that the coroutine completes the task corresponding to the task request.

[0065] In this embodiment, a task request is a request for processing a task through a coroutine. After obtaining the task request of the application, the execution subject calls a function in the dynamic runtime library to generate at least one coroutine corresponding to the task request, or calls a function in the dynamic runtime library to collect existing coroutines corresponding to the task request. Different coroutine scheduling threads are distinguished based on the coroutine context of the coroutine. The execution subject sends the coroutine to the corresponding coroutine scheduling thread. The coroutine scheduling thread schedules at least one coroutine to make each coroutine work and complete the task corresponding to the task request.

[0066] The runtime virtualization method provided by the embodiment of the present disclosure firstly builds a dynamic runtime library based on the native runtime library of the application; secondly, loads the dynamic runtime library when starting the application, generates a runtime virtualization environment and a coroutine scheduling thread running in the runtime virtualization environment, the coroutine scheduling thread is used to schedule at least one coroutine, and the runtime virtualization environment is the environment after replacing the runtime environment generated by the native runtime library; thirdly, in the runtime virtualization environment, receives the task request of the application; finally, based on the task request and the dynamic runtime library, the coroutine scheduling thread is used to schedule the coroutine so that the coroutine completes the task corresponding to the task request. Therefore, the present disclosure generates a runtime virtualization environment through a dynamic runtime library, transparently replaces the runtime environment of the application, and improves the concurrent performance of the application without making any modification or recompiling to the application; the thread-capable coroutine generated by the dynamic runtime library supports lightweight coroutine scheduling, which can 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.

[0067] In some optional implementations of this embodiment, based on the task request and the dynamic runtime library, a coroutine scheduling thread is used to schedule the coroutine so that the coroutine completes the task corresponding to the task request, including: creating at least one coroutine based on the task request and the dynamic runtime library; sending at least one coroutine to the coroutine scheduling thread, so as to use the coroutine scheduling thread to schedule at least one coroutine.

[0068] In this embodiment, the creation of at least one coroutine based on the task request and the dynamic runtime library includes: determining the task based on the task request; scheduling the thread library function hook in the dynamic runtime library, and creating a coroutine corresponding to the task through the thread library function hook. The thread library function hook is obtained by hooking with the first library function, and the first library function is a library function in the native runtime library that creates a thread and obtains a thread descriptor.

[0069] The method of scheduling coroutines by using coroutine scheduling threads provided in this embodiment first constructs a coroutine corresponding to a task request by means of constructing threads, so that the obtained coroutine has the same capability as a thread; secondly, the constructed coroutine is scheduled by using coroutine scheduling threads, thereby improving the task execution efficiency.

[0070] In some optional implementations of the present embodiment, the coroutine scheduling thread includes: a scheduler and a lock-free queue for placing at least one coroutine, and scheduling at least one coroutine using the coroutine scheduling thread includes: 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 voluntarily 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 voluntarily gives up, the scheduler continues to obtain coroutines from the lock-free queue and synchronize the thread control block until there is no coroutine in the lock-free queue.

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

[0072] 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_getspecific 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).

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

[0074] The coroutine scheduling thread provided in this embodiment has a scheduler and a lock-free queue. The coroutines in the lock-free queue are scheduled by the scheduler to implement the tasks requested by the application program. In addition, since the coroutine scheduling thread will not be suspended by any operation, the reliability of task execution is guaranteed.

[0075] In another embodiment of the present disclosure, the method further includes: receiving a native request of an application; creating at least one thread based on the native request and a native runtime library in a dynamic runtime library, and executing a task corresponding to the native request through the at least one thread.

[0076] In this embodiment, the native request is a request for the application to call a library function in the native runtime library to generate a thread. The above-mentioned creation of at least one thread based on the native request and the native runtime library in the dynamic runtime library includes: determining a thread creation task based on the native request; calling a function for creating a native thread from the native runtime library based on the thread creation task, and creating at least one thread that executes the task corresponding to the native request.

[0077] The runtime virtualization method provided in this embodiment retains the capabilities of the native runtime library through the dynamic runtime library. When the application needs to schedule the construction thread function of the native runtime library, at least one thread is created, and the task corresponding to the native request is executed through at least one thread, thereby improving the diversity of request execution and ensuring the compatibility of threads and coroutines.

[0078] In view of the fact that the traditional coroutine library does not implement coroutine simulation of thread local storage, and the problem of unsafe use of thread local storage in coroutines, in some open optional implementation methods, the above-mentioned native runtime library based on the application and the construction of the dynamic runtime library include:

[0079] A hook mechanism is used to construct a thread library function hook related to a first library function. The first library function is a library function in a native runtime library that creates a thread and obtains a thread descriptor. In the thread library function hook, a coroutine context structure is used to replace the thread descriptor, and a global variable with a thread local constraint is used to mark the current running thread or coroutine. The thread local storage information in the coroutine context structure is managed by a 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 dynamic runtime 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 dynamic runtime 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 no longer needs 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. An incremental backup of the TCB dtv is stored in the scheduler COCTX to describe the incremental part of the dtv generated each time the dynamic library is loaded. At the same time, it is necessary to hook the library function call for loading 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 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 scheduler COCTX; then, when a coroutine needs to be swapped in (resume), check whether there is a difference between the coroutine and the dtv incremental backup (if there is, synchronization is required), and after the difference synchronization is completed, _current_coctx is set as the context of the current coroutine; finally, when the coroutine requires 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] This embodiment implements pure user-mode coroutine TLS switching, maintaining the lightweight characteristics of coroutine switching while maintaining the cross-coroutine security of TLS (taking into account both high performance and "transparent" virtualization).

[0097] This embodiment provides a method for building a dynamic runtime library, constructs a thread library function hook of the first library function in the native runtime library through a hook mechanism, replaces the original thread descriptor of the thread through the coroutine context in the thread library function hook, marks the current running subject through a global variable, and manages the thread local storage information in the coroutine context structure through a synchronization management module, so that the constructed coroutine has the same capability as the thread, and improves the reliability of coroutine scheduling when the thread schedules the coroutine.

[0098] In the traditional technology, the coroutine library does not properly solve the compatibility problem between coroutine locks and thread locks. In some optional implementations disclosed, the above-mentioned native runtime library based on the application and the construction of the dynamic runtime library also include:

[0099] A hook mechanism is used to construct a lock library function hook related to the second library function. The second library function is a library function in the native runtime library that is related to locks, conditional variables, and semaphores respectively. In the lock library function hook, 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.

[0100] In this optional implementation, based on the application's request, the currently running subject can be a coroutine built by the dynamic runtime library, or a thread built by running the native runtime library; through global variables, it can be identified whether the type of the running subject is a coroutine or a thread. When the running subject is a thread, the thread library function hook further determines whether the current running subject is a coroutine scheduling thread or other threads. When the current running subject is a coroutine scheduling thread, no lock or semaphore mechanism is used. Through this mechanism, it can be ensured that the coroutine scheduling thread will not suspend itself due to the use of locks or semaphores.

[0101] When the current running subject is a thread other than the coroutine scheduling thread (such as the main thread or native thread), based on the current operating system, the lock mechanism corresponding to the operating system is used to transmit the wake-up signal. For example, when the operating system is a Linux system, the futex mechanism is used to transmit the wake-up signal; when the operating system is a non-Linux system, the pipeline communication and pollwait method are used to transmit the wake-up signal.

[0102] Futex mechanism: A synchronization mechanism that mixes user state and kernel state, and is one of the basic components of Linux. The state synchronization between user state and kernel state is carried out through atomic operations based on a shared memory segment. The user state process uses atomic operations to determine whether there is resource competition for the futex variable. If waiting is required, it will fall into the system call to suspend the thread; when waking up the futex, it will also first check whether there is a task that is suspended and waiting through atomic operations. Only when waking up is required will it fall into the system call to perform the "wake up" operation. In short, it is to avoid falling into the kernel state when there is no resource competition through user state atomic operations, thereby greatly improving the operating efficiency in the "low contention" scenario.

[0103] In this optional implementation, the above-mentioned current running subject can also be an operation object without a timeout waiting operation and an operation object with a timeout waiting operation. The above-mentioned lock mechanism corresponding to the current running subject is given based on the current running subject, including: for operations without a timeout waiting, directly putting the coroutine context structure into the waiting queue of the lock object or the condition variable object, and calling the "suspend" method of the coroutine context structure (yield in coroutine mode).

[0104] For operations with timeout waiting, the coroutine context structure needs to be placed in the corresponding waiting queue and time queue at the same time, and then the "suspend" method is called on the coroutine context structure.

[0105] This embodiment implements a "transparent" lock mechanism that is compatible with coroutines and threads. In the hook of the lock-related library function in the C runtime library, it automatically identifies whether the current context is a coroutine context or a thread context, so as to adopt different behavior modes.

[0106] The lock library function hook construction method provided by this optional implementation hooks the thread lock related library functions in the native runtime library, implements a lock solution that is compatible with both threads and coroutines, and ensures the compatibility of thread locks and coroutine locks in the runtime virtual machine system.

[0107] In some optional implementations of the present disclosure, the above-mentioned native runtime library based on the application program, building the dynamic runtime library further includes:

[0108] A hook mechanism is used to construct a switching library function hook related to a third library function, where the third library function is a library function in a native runtime library that can cause a thread switch or suspend operation; the switching library function hook is used to use a coroutine switch or suspend mechanism instead of a thread switch or suspend mechanism.

[0109] The switching library function hook construction method provided by this optional implementation hooks the functions in the native runtime library that can cause thread switching or suspension operations. The coroutine switching and suspension method can be adopted when switching or suspending threads, thereby improving the concurrent performance of the operating system.

[0110] Further references Figure 2 As an implementation of the runtime virtualization method shown in the above figures, the present disclosure provides an embodiment of a runtime virtualization device. Figure 2 Corresponding to the method embodiment shown, the device can be specifically applied to various electronic devices.

[0111] like Figure 2 As shown, an embodiment of the present disclosure provides a runtime virtualization device 200, which includes: a construction unit 201, a generation unit 202, a task receiving unit 203, and a coroutine scheduling unit 204. Among them, the above-mentioned construction unit 201 can be configured to build a dynamic runtime library based on the native runtime library of the application, and the dynamic runtime library simulates the thread implemented in the native runtime library in a coroutine manner. The above-mentioned generation unit 202 can be configured to load the dynamic runtime library when starting the application, generate a runtime virtualization environment and a coroutine scheduling thread running in the runtime virtualization environment, and the coroutine scheduling thread is used to schedule at least one coroutine, and the runtime virtualization environment is an environment after replacing the runtime environment generated by the native runtime library. The above-mentioned task receiving unit 203 can be configured to receive a task request of the application under the runtime virtualization environment. The above-mentioned coroutine scheduling unit 204 can be configured to schedule the coroutine using the coroutine scheduling thread based on the task request and the dynamic runtime library, so that the coroutine completes the task corresponding to the task request.

[0112] In this embodiment, the specific processing of the construction unit 201, the generation unit 202, the task receiving unit 203, and the coroutine scheduling unit 204 and the technical effects thereof can be referred to in the respective Figure 1 Corresponding to step 101, step 102, step 103, and step 104 in the embodiment.

[0113] In some embodiments, the scheduling unit 204 is configured to: create at least one coroutine based on the task request and the dynamic runtime library; send at least one coroutine to the coroutine scheduling thread to schedule the at least one coroutine using the coroutine scheduling thread.

[0114] In some embodiments, the above-mentioned coroutine scheduling thread includes: a scheduler and a lock-free queue for placing at least one coroutine, and the scheduling unit 204 is further configured as: 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.

[0115] In some embodiments, the above-mentioned device 200 also includes: a native receiving unit, configured to receive a native request of an application; a thread scheduling unit, configured to create at least one thread based on the native request and the dynamic runtime library, and execute the task corresponding to the native request through the at least one thread.

[0116] In some embodiments, the above-mentioned construction unit 201 is configured to: use a hook mechanism to construct a thread library function hook related to the first library function, and the first library function is a library function in the native runtime library that creates a thread and obtains a thread descriptor; in the thread 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 a thread local constraint, and the thread local storage information in the coroutine context structure is managed by a 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.

[0117] In some embodiments, the above-mentioned construction unit 201 is configured to: use a hook mechanism to construct a lock library function hook related to the second library function, and the second library function is a library function in the native runtime library that is respectively related to locks, conditional variables, and semaphores; in the lock library function hook, the current running subject is judged through global variables, and based on the current running subject, a corresponding lock mechanism is given to the current running subject.

[0118] In some embodiments, the above-mentioned construction unit 201 is configured to: use a hook mechanism to construct a switching library function hook related to a third library function, where the third library function is a library function in the native runtime library that can cause a thread switching or suspension operation; the switching library function hook is used to use a coroutine switching or suspension mechanism instead of a thread switching or suspension mechanism.

[0119] The runtime virtualization device provided by the embodiment of the present disclosure, first, the construction unit 201 constructs a dynamic runtime library based on the native runtime library of the application; secondly, the generation unit 202 loads the dynamic runtime library when starting the application, generates a runtime virtualization environment and a coroutine scheduling thread running in the runtime virtualization environment, the coroutine scheduling thread is used to schedule at least one coroutine, and the runtime virtualization environment is the environment after replacing the runtime environment generated by the native runtime library; thirdly, the task receiving unit 203 receives the task request of the application in the runtime virtualization environment; finally, the coroutine scheduling unit 204 uses the coroutine scheduling thread to schedule the coroutine based on the task request and the dynamic runtime library, so that the coroutine completes the task corresponding to the task request. Therefore, the present disclosure generates a runtime virtualization environment through a dynamic runtime library, transparently replaces the runtime environment of the application, and improves the concurrent performance of the application without any modification or recompilation of the application; the thread-capable coroutine generated by the dynamic runtime library supports lightweight coroutine scheduling, which can 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.

[0120] In view of the above-mentioned runtime virtualization method, the present disclosure provides a runtime virtual machine system, which can be specifically applied to various electronic devices.

[0121] like Figure 3 As shown, an embodiment of the present disclosure provides a runtime virtual machine system 300, which includes: a main thread 302, a coroutine scheduling thread 303, an event-driven thread 304, and an asynchronous input and output and timer thread 305 running in a runtime virtualization environment 301, wherein the runtime virtualization environment 301 is generated by loading a dynamic runtime library, and the dynamic runtime library is constructed based on the native runtime library of the application, and the dynamic runtime library simulates the threads implemented in the native runtime library in a coroutine manner; the coroutine scheduling thread 303 is used to schedule at least one coroutine so that the coroutine completes the task request of the application; the main thread 302 is created when the application starts; the event-driven thread 304 is used to maintain the status of the file handle, and wake up the corresponding coroutine when the read or write cache is ready and there is a read and write task blocked on the file handle; the asynchronous input and output and timer thread 305 obtains the asynchronous input and output task result and wakes up the coroutine in IO waiting; when the system call times out and returns, the task that has been exhausted by the timeout is popped up and woke up; when the system calls the asynchronous IO task result, wakes up the coroutine in IO waiting.

[0122] The main thread 302 is created when the application starts and can be regarded as a special system native thread.

[0123] Coroutine scheduling thread 303, the coroutine scheduling thread is responsible for repeatedly taking out the ready coroutine tasks from the lock-free queue, using the resume (including the coroutine that has just been started) method to swap in the coroutine context, and continue to execute the corresponding coroutine. When a coroutine yields (yield, including the end of the coroutine), if it is a non-waiting coroutine (that is, it just temporarily gives up the CPU), the corresponding coroutine needs to be put back into the wake-up queue and re-scheduled. The runtime virtual machine system of the present disclosure uses the boost context library in practice to implement the switching of the coroutine stack and the swapping in and out of the coroutine function.

[0124] The asynchronous input / output and timer thread 305, the background part of asynchronous IO and timer, can be implemented in the same background thread. This is because the system call interface for waiting for asynchronous IO events can specify a timeout, and the time accuracy of such timeouts is high enough to be suitable for the implementation of timers. As a background thread with lower load, merging the functions of the above two will help further reduce the number of background threads. The asynchronous input / output and timer thread 305 interacts with other components in the system through two data structures:

[0125] AIO task queue: used to deliver io_event of asynchronous IO tasks. After the background thread calls io_getevents and returns the result, it will search this queue, deliver the IO operation result, and wake up the coroutine that is waiting for IO.

[0126] Timed queue: manages the coroutine context of the timeout waiting state. This queue stores a key-value structure with the timeout as the key and COCTX as the value, and is sorted by key value (the task with a smaller key value, that is, the task with the shortest time interval from the current time interval, is ranked first).

[0127] The background thread repeatedly calls the io_getevents system call. When this call times out, it processes the timed queue, pops out the timed-out task (which may be a coroutine or a native thread) and wakes it up. When the system call returns the result of the asynchronous IO task, it passes the content of the io_event structure and wakes up the corresponding coroutine.

[0128] The event-driven thread 304, also called the Epoll thread, is responsible for maintaining the POLLIN & POLLOUT status of all file handles that have been opened in the system and support poll operations. Because the dynamic runtime has hooked library functions including socket, open, close, etc., when the file handle (mainly socket) is just created, it is placed in the sockfd map for maintenance. This thread repeatedly updates the read / write cache status of all file handles in the sockfd map by calling epoll_wait. When the read / write cache is ready and there is a read / write task or poll wait task blocked on this file handle (such as a coroutine stuck in waiting in library function hooks such as poll, select, epoll_wait), the corresponding coroutine is awakened.

[0129] For the above-mentioned runtime virtual machine system, to minimize the start of an application that mounts a runtime virtual machine, only 4 threads need to be created, namely: 1 main thread, 1 coroutine scheduling thread, 1 event-driven thread, and 1 asynchronous input and output and timer thread. Even if the process is started with the above-mentioned minimized resource configuration (that is, only 4 threads are required), hundreds of small concurrent tasks can still be easily managed without lag. When faced with large applications with relatively high resource utilization (such as databases), you can consider using the same number of coroutine scheduling threads as the number of host CPU cores, and configure other background threads in a proportionally reduced manner. In other words, whether it is a small task multi-process or a large task multi-threaded application scenario, the runtime virtual machine disclosed in the present invention can provide good support. Specific examples are as follows:

[0130] In the first case, all processes are started with a minimal configuration (4 threads), and the load of each process is an average of 100 small tasks. When 1,000 processes are started, the overall system load reaches 100,000 concurrent tasks, but only 4,000 threads need to be created.

[0131] In the second case, only one large application (such as a database) is started in a 64-core system, including: 1 main thread, 64 coroutine scheduling threads, 8 epoll threads, 8 AIO / timer threads, 10 database background threads (such as publishing and subscription, backup and recovery, monitoring, log cleaning, table space recycling and sorting, etc., all use system native threads), a total of 91 threads. This configuration is enough to handle tens of thousands of concurrent database accesses, and the total number of threads is less than 100.

[0132] The runtime virtual machine system provided by the embodiment of the present disclosure provides a complete set of coroutine dynamic runtime libraries through dynamic library injection technology. All ways of interacting with the operating system have been taken over by the dynamically running library function hooks in the present disclosure (that is, a complete set of coroutine version library functions are implemented). The application program is virtually run on another virtual system that is fully compatible with the native system, namely the coroutine virtualization environment. Any application in the host system can run directly in the coroutine virtual environment without any modification, thereby transparently implementing the solution of coroutines replacing threads.

[0133] In another embodiment of the present disclosure, a runtime virtual machine system 400 is provided, which includes: a main thread 402 running in a runtime virtualization environment 401, a coroutine scheduling thread 403, an event-driven thread 404, an asynchronous input and output and timer thread 305, and a system native thread 306.

[0134] Relative to Figure 3 The embodiment shown, Figure 4 In the embodiment shown, there is a system native thread 306, Figure 4 The embodiment shown is relative to Figure 3 In the illustrated embodiment, the generated dynamic runtime retains the features of the native runtime, and the native runtime can be called upon by the application program to generate a system native thread 306 when required.

[0135] Since the library functions related to thread management have been hooked, by default, all coroutines are created after the dynamic runtime library is loaded. When the application needs to generate a system native thread, the user can choose to start the corresponding thread as a native thread by specifying the function name of the thread function; or dynamically specify whether a newly created thread is started as a coroutine or a native thread by implementing the callback interface corresponding to the library function that creates the thread.

[0136] Optionally, the runtime virtual machine system provided by this embodiment, in addition to common interfaces such as parameter configuration interface and log interface, can also implement a set of callback interfaces, and most of the library function hooks in the dynamic runtime library can be equipped with corresponding callback functions. Developers can choose to implement some or all callbacks, or not use any callbacks. Through these callback interfaces, developers can partially change the behavior of library functions, or even completely take over certain specific library functions, thereby achieving such as:

[0137] Some optimizations that originally required modifying the underlying system mechanism to be implemented are directly injected into the library function; and this injection is only for the current application and will not affect other running programs;

[0138] Based on the runtime virtual machine system disclosed in this disclosure, secondary development is carried out to realize another runtime virtual machine system. (For example, taking over all library functions related to file IO, changing local file reading and writing to cloud disk reading and writing, you can realize a runtime virtual machine based on cloud disk)

[0139] Taking a callback of a recv (receive network packet) interface as an example, the operation logic of the callback function in the runtime virtual machine system of the present disclosure is explained. When the developer specifies the callback function, the recv function of the runtime virtual machine system of the present disclosure will first pass the network packet received from the socket to the callback function, and determine the final return method of the recv function based on the return value of the callback function. The callback function can choose not to intervene and directly return the packet; it can also choose to discard the packet; or even further modify the content of the packet and return the modified packet to the application.

[0140] The runtime virtual machine system provided in this embodiment provides a callback interface. Developers can implement callback functions to inject new logic into the hook of the coroutine library or completely change the logic of the hook function, thereby expanding and enhancing the original application, or using this runtime virtual machine framework to implement a new runtime virtualization environment.

[0141] Reference below Figure 5 , which shows a structural schematic diagram of an electronic device 500 suitable for implementing an embodiment of the present disclosure.

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

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

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

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

[0146] 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: builds a dynamic runtime based on the native runtime of the application; loads the dynamic runtime when starting the application, generates a coroutine scheduling thread, and the coroutine scheduling thread is used to schedule at least one coroutine; receives a task request from the application; and based on the task request and the dynamic runtime, schedules the coroutine using the coroutine scheduling thread so that the coroutine completes the task corresponding to the task request.

[0147] 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).

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

[0149] 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 provided in a processor, for example, may be described as: a processor comprising a construction unit, a generation unit, a task receiving unit, and a coroutine scheduling unit. Among them, the names of these units do not constitute a limitation on the unit itself in some cases, for example, the construction unit may also be described as a unit "configured to build a dynamic runtime based on the native runtime of the application".

[0150] 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 virtualization method, the method comprising: Based on the native runtime library of the application, a dynamic runtime library is constructed, wherein the dynamic runtime library simulates the threads implemented in the native runtime library in a coroutine manner; When starting the application, the dynamic runtime library is loaded to generate a runtime virtualization environment and a coroutine scheduling thread running in the runtime virtualization environment, wherein the coroutine scheduling thread is used to schedule at least one coroutine, and the runtime virtualization environment is an environment after replacing the runtime environment generated by the native runtime library; In the runtime virtualization environment, receiving a task request of the application program; Based on the task request and the dynamic runtime library, the coroutine scheduling thread is used to schedule the coroutine so that the coroutine completes the task corresponding to the task request.

2. The method according to claim 1, wherein: The step of scheduling the coroutine using the coroutine scheduling thread based on the task request and the dynamic runtime library so that the coroutine completes the task corresponding to the task request includes: Based on the task request and the dynamic runtime library, create at least one coroutine; The at least one coroutine is sent to the coroutine scheduling thread, so that the at least one coroutine is scheduled by the coroutine scheduling thread.

3. The method according to claim 2, wherein: The coroutine scheduling thread includes: a scheduler and a lock-free queue for placing the at least one coroutine, and the use of the coroutine scheduling thread to schedule the at least one coroutine includes: The scheduler obtains a coroutine in a ready state from the at least one coroutine in the lock-free queue; Synchronize the coroutine context of the coroutine with the thread context in the thread control block; After the coroutine voluntarily 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 voluntarily yields, 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.

4. The method according to claim 1, wherein: The method further comprises: receiving a native request from the application; At least one thread is created based on the native request and the native runtime library in the dynamic runtime library, and the task corresponding to the native request is executed through the at least one thread.

5. The method according to any one of claims 1 to 4, wherein: The construction of the dynamic runtime library based on the native runtime library of the application includes: A thread library function hook related to a first library function is constructed by using a hook mechanism, wherein the first library function is a library function for creating a thread and obtaining a thread descriptor in the native runtime library; In the thread 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 a 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.

6. The method according to claim 5, wherein: The native runtime library based on the application program and the construction of the dynamic runtime library further include: A lock library function hook related to a second library function is constructed by using a hook mechanism, wherein the second library function is a library function in the native runtime library that is respectively related to a lock, a conditional variable, and a semaphore; In the lock library function hook, the current running subject is judged through the global variable, and based on the current running subject, a corresponding lock mechanism is given to the current running subject.

7. The method according to claim 5, wherein: The native runtime library based on the application program and the construction of the dynamic runtime library further include: A hook mechanism is used to construct a switch library function hook related to a third library function, wherein the third library function is a library function in the native runtime library that can cause a thread switch or a suspend operation; The switching library function hook is used to adopt a coroutine switching or suspension mechanism instead of a thread switching or suspension mechanism.

8. A runtime virtualization device, the device comprising: A construction unit is configured to construct a dynamic runtime library based on a native runtime library of an application program, wherein the dynamic runtime library simulates threads implemented in the native runtime library in a coroutine manner; a generating unit configured to load the dynamic runtime library when starting the application, generate a runtime virtualization environment and a coroutine scheduling thread running in the runtime virtualization environment, wherein the coroutine scheduling thread is used to schedule at least one coroutine, and the runtime virtualization environment is an environment after replacing the runtime environment generated by the native runtime library; A task receiving unit is configured to receive a task request of the application program in the runtime virtualization environment; The coroutine scheduling unit is configured to use the coroutine scheduling thread to schedule the coroutine based on the task request and the dynamic runtime library, so that the coroutine completes the task corresponding to the task request.

9. A runtime virtual machine system, the system comprising: A coroutine scheduling thread, a main thread, an event-driven (EPOLL) thread, an asynchronous input and output (AIO), and a timer thread running in a runtime virtualization environment, wherein the runtime virtualization environment is generated by loading a dynamic runtime library, and the dynamic runtime library is constructed based on a native runtime library of an application program, and the dynamic runtime library simulates the threads implemented in the native runtime library in a coroutine manner; The coroutine scheduling thread is used to schedule at least one coroutine so that the coroutine completes the task request of the application program; The main thread is created when the application is started; The event-driven thread is used to maintain the state of the file handle and wake up the corresponding coroutine when the read or write cache is ready and there is a read or write task blocked on the file handle; The asynchronous input and output and timer threads obtain the asynchronous input and output task results and wake up the coroutine in IO waiting; when the system call returns with timeout, the task with timeout is popped out and woke up; when the system calls the asynchronous IO task results, the coroutine in IO waiting is woken up.

10. 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 any one of claims 1 to 7.

11. A computer readable medium having a computer program stored thereon, wherein: When the program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images