Serialization-free communication method and system and computer readable storage medium

Abstract

The invention discloses a serialization-free communication method and system and a computer readable storage medium, the serialization-free communication method is applied to a mobile terminal system, the system comprises a plurality of processes, and the processes communicate through a shared kernel. Wherein the kernel is used for running a first sandbox program in a programmable sandbox environment, converting an original memory address and metadata of a first object sent by a first process into first data and storing the first data into a first buffer area, and the first sandbox program is matched and determined from a plurality of sandbox programs according to the metadata of the first object; and sending the first address of the first data in the first buffer area to the second process, so that the second process determines a second object according to the first address of the first data in the first buffer area. According to the method, the sandbox program runs in the programmable sandbox environment, so that the serialization-free communication method is suitable for a complex communication scene with self-defined serialization and deserialization logic, and the security of a communication process and a kernel is guaranteed.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a serialization-free communication method, system, and computer-readable storage medium. Background Art

[0002] At present, in order to improve communication performance and reduce the large overhead of serialization / deserialization during inter-process communication, there are many improvement solutions such as reducing the amount of transmitted data and adopting a cache mechanism, but these methods are limited in application scenarios, so serialization-free communication technology is further proposed. One of the serialization-free communication technologies allows Java applications to directly access the send / receive objects through remote direct memory access (RDMA) or transmission control protocol (TCP) connections.

[0003] However, the above method can only send the object to be sent completely. When the original serialization and deserialization logic is not a simple field copy and there are some special processing operations, it lacks support for such special processing, that is, support for custom object copy logic, and cannot meet the needs of complex communication scenarios such as the Binder mechanism in the Android operating system. Summary of the invention

[0004] The present application provides a serialization-free communication method, system and computer-readable storage medium. By running a first sandbox program in a programmable sandbox environment through the kernel, the object to be sent is copied from the sending end to the receiving end. The serialization-free communication method can be applied in complex communication scenarios with custom serialization and deserialization logic, thereby ensuring the security of the communication process and the kernel.

[0005] In the first aspect, the present application provides a mobile terminal system, which includes multiple processes, and the multiple processes communicate with each other through a shared kernel. The kernel is used to run a first sandbox program in a programmable sandbox environment, determine the first data according to the original memory address and metadata of the first object sent by the first process, and store it in a first buffer, wherein the first sandbox program is determined by matching from multiple sandbox programs according to the metadata of the first object, and the first buffer is a part of the serialization-free memory block registered by the second process to the kernel; the kernel is also used to send the first data at the first address of the first buffer to the second process, so that the second process determines the second object according to the first data at the first address of the first buffer, and the second object is applicable to the second process.

[0006] To sum up, in the above system, the kernel runs the first sandbox program in a programmable sandbox environment to copy the object to be sent from the sending end to the receiving end, thereby realizing the application of the serialization-free communication method in complex communication scenarios with custom serialization and deserialization logic, and can ensure the secure isolation of the first process and the second process, and minimize the security risks and maintenance costs brought about by the introduction of custom serialization and deserialization logic.

[0007] In a possible implementation, the programmable sandbox includes one or more sandbox programs loaded under a fixed directory of the system, and one or more sandbox programs that update the loaded sandbox programs, and each of the one or more sandbox programs is generated according to the serialization and deserialization logic of the process communication. The sandbox program is generated according to the serialization and deserialization logic of the process communication and the memory layout file of the first object. After being injected into the programmable sandbox, the application of the serialization-free communication method in complex communication scenarios with custom serialization and deserialization logic can be realized. The programmable sandbox can also isolate the sandbox program to prevent the kernel from being attacked and ensure security. The above-mentioned updating of the loaded sandbox program can improve development efficiency, and specifically, the loaded sandbox program can be updated through the command line. One or more sandbox programs injected into the programmable sandbox are all subjected to security verification, for example, whether there is a dead loop in the sandbox program, etc., and if there is a dead loop, etc., the sandbox program is not injected into the programmable sandbox, thereby ensuring the normal progress of the subsequent serialization-free communication process.

[0008] In a possible implementation, the kernel is specifically used to, according to the first sandbox program and the original memory address of the first object, traverse the first object, determine the total size of the first object, and determine the size of the first buffer, wherein the total size of the first object includes the size of the first object and the size of the sub-object referenced by the first object; run the first sandbox program in a programmable sandbox environment, determine the first data according to the original memory address and metadata of the first object sent by the first process; and store the first data in the first buffer. The above process can determine a suitable buffer, support custom serialization and deserialization logic by running the first sandbox program in an isolated environment, and ensure the security of the process and the kernel.

[0009] In a possible implementation, the kernel is specifically used to: when the field in the first object is a common type field, store the common type field as the first data in the first buffer; when the field in the first object is a reference type field, perform reference repair according to the first sandbox program and the size of the first object, determine the new reference field, and store the new reference field as the first data in the first buffer; when the field in the first object is a type field and is different from the type field registered with the kernel by the second process, store the new address of the type corresponding to the second process as the first data in the first buffer, and the type corresponding to the second process is determined according to the type field in the first object. The first data includes one or more of a new object, an unprocessed common type field, a specially processed new reference type field, and a new address of the type corresponding to the second process. The first data is determined according to the metadata of the first object and the first sandbox program, and the application of custom serialization and deserialization logic can be implemented in serialization-free communication.

[0010] In one possible implementation, before the kernel is used to run the first sandbox program in a programmable sandbox environment, the second process is used to: register the address of the first metadata and the serialization-free memory block including the serialization-free mark with the kernel, the first metadata is used to record the usage of the serialization-free memory block and is updated by the kernel. The second process performs a serialization-free mark on the serialization-free memory block registered with the kernel, so that the serialization-free memory block is not used by the second process for memory allocation during the serialization-free communication process and is not cleared by the garbage collection process running in the second process, thereby realizing a synchronization mechanism between the kernel and the second process. The kernel and the second process jointly manage the serialization-free memory block, thereby ensuring that there are always available serialization-free memory blocks in the kernel to write new data determined according to the object to be sent.

[0011] In a possible implementation, the second process is also used to: register a new non-serialized memory block and remove the non-serialized mark corresponding to the non-serialized memory block when it is determined according to the first metadata that the non-serialized memory block no longer writes data, so that the non-serialized memory block is recycled by the garbage collection (GC) process in the second process. The first metadata registered by the second process to the kernel may include size information of each memory block, status information of the memory block (such as whether the memory block is allocated or unallocated, etc.), and process information allocated to the memory block, etc. After the communication is completed and the kernel updates the first metadata, the second process determines whether the memory block can continue to receive data in the subsequent communication process according to the updated first metadata, so that when the non-serialized memory block no longer writes data, register a new non-serialized memory block with the kernel, move the non-serialized memory block into a to-be-cleaned list, remove the non-serialized mark corresponding to the non-serialized memory block in the to-be-cleaned list, so that the non-serialized memory block is removed when the next garbage collection is run.

[0012] In a possible implementation, the first process is also used to: prevent the execution of the garbage collection process in the first process, or delay the execution of the recovery phase of the garbage collection process in the first process. The above process can implement a synchronization mechanism between the first process and the kernel during serialization-free communication to ensure that the object to be sent is not destroyed by the garbage collection process, wherein for a specific type of garbage collection process (such as copying garbage collection (Copying GC)), the method of delaying the recovery phase is adopted, which has lower overhead than the method of preventing the garbage collection process.

[0013] In the second aspect, the present application provides a serialization-free communication method, which is applied to the mobile terminal system described in the first aspect, in which multiple processes with a common kernel are running, and the multiple processes communicate with each other through the kernel. The method includes: the kernel runs a first sandbox program in a programmable sandbox environment, converts the original memory address and metadata of the first object sent by the first process into first data, and stores it in a first buffer, wherein the first sandbox program is determined by matching from multiple sandbox programs based on the metadata of the first object, and the first buffer is a part of the serialization-free memory block registered by the second process to the kernel; the kernel sends the first data at the first address of the first buffer to the second process, so that the second process determines the second object according to the first data at the first address of the first buffer, and the second object is applicable to the second process.

[0014] In a third aspect, the present application provides a communication device, which runs the mobile terminal system provided in the first aspect, and the communication device includes a processor and a memory, and the processor is used to execute instructions stored in the memory of the communication device so that the communication device executes the method provided in the second aspect.

[0015] In a fourth aspect, the present application provides a computer program product comprising instructions, which, when executed by a communication device, causes the communication device to execute the method provided in the second aspect.

[0016] In a fifth aspect, the present application provides a computer-readable storage medium, which includes computer program instructions. When the computer program instructions are executed by a communication device, the communication device executes the method provided in the second aspect.

[0017] Based on the implementations provided in the above aspects, this application can also be further combined to provide more implementations. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following briefly introduces the drawings required for describing the embodiments.

[0019] Figure 1 This is a schematic diagram of a process of serialization-free communication in an inter-process communication scenario provided by an embodiment of the present application;

[0020] Figure 2 It is a structural diagram of a mobile terminal system provided in an embodiment of the present application;

[0021] Figure 3 It is a structural diagram of a communication device provided in an embodiment of the present application;

[0022] Figure 4 is a flow chart of a serialization-free communication method provided in an embodiment of the present application;

[0023] Figure 5 is a flow chart of a sandbox program generation method provided by an embodiment of the present application;

[0024] Figure 6 This is a workflow diagram of a sandbox program automatic generator provided in an embodiment of the present application;

[0025] Figure 7 This is a flow chart of a sandbox program injection provided by an embodiment of the present application;

[0026] Figure 8 This is a schematic diagram of a process of synchronization between a sending end process and a kernel provided in an embodiment of the present application;

[0027] Fig. 9 It is a schematic diagram of the time relationship between a serialization-free communication and GC provided in an embodiment of the present application;

[0028] Fig.10 It is a schematic diagram of a delayed Reclaim process provided by an embodiment of the present application;

[0029] Fig.11 It is a schematic diagram of the system structure that supports serialization-free communication between Java processes through Binder communication provided in an embodiment of the present application. DETAILED DESCRIPTION

[0030] At present, in the total overhead of binder communication, the serialization / deserialization overhead accounts for a large proportion, which affects the communication performance. In order to reduce the serialization / deserialization overhead in the process of process communication, a variety of improvement schemes such as reducing the amount of transmitted data or caching mechanism can be adopted. Among them, in the method of reducing the amount of transmitted data, the communicating parties agree on some transmission rules, such as sending only one copy of redundant fields, not sending field types, or performing data compression, etc., to reduce the amount of data involved in serialization / deserialization, thereby reducing the overhead, but this method is only applicable to some scenarios with more redundant data or higher transmission delay. The cache mechanism is adopted, that is, by caching the call result at the sending end, it is used directly when the next call result is the same. The above method is also only applicable to scenarios where the results of inter-process communication calls change less, and cache requires additional memory consumption. In order to solve the defects of the above improvement scheme, a serialization-free communication technology is further proposed.

[0031] Among them, a non-serialization communication technology enables applications to directly access the sending / receiving objects and the metadata of the objects through remote direct memory access (RDMA) or transmission control protocol (TCP) connections. The above process can send the object to be sent completely to the remote end, but in addition to simple field copying, there are special processing in the serialization / deserialization logic (for example, the object to be sent defines its own corresponding serialization / deserialization logic, in which some fields do not participate in serialization / deserialization, or some repeated fields are only serialized / deserialized once, etc.), then it is impossible to support the custom serialization and deserialization logic in the process of non-serialization communication, and it is impossible to meet the needs of complex communication scenarios such as Android Binder. In another non-serialization communication technology, the sending process and the receiving process each pre-allocate a dedicated memory space for non-serialization communication with a completely consistent memory layout, and store all type information involved in non-serialization transmission in a memory space similar to distributed shared memory, ensuring that the memory address where the information is stored is completely consistent, and realizing direct reading and writing of objects, thereby avoiding the problem that the sending object changes the object address and type address, and requires type repair and reference repair. However, this method can only achieve simple copying of objects and cannot achieve the above functions in scenarios with custom serialization and deserialization logic. It also cannot meet the needs of complex communication scenarios such as Android Binder.

[0032] In addition to the above two specific serialization-free communication technologies, the present application embodiment provides a schematic diagram of the process of serialization-free communication in an inter-process communication scenario, as shown in FIG. Figure 1 As shown. Figure 1It can be determined that the serialization-free communication includes the following steps: the receiving process registers the heap space used to store the receiving object in the serialization-free communication to the kernel, the sending process sends the address of the object to be sent in the heap space to the kernel, the kernel's custom serialization and deserialization logic copies the sending object to the heap space of the receiving process, and sends the address of the receiving object in the heap space of the receiving process to the receiving process, and finally, the receiving process determines the receiving object according to the address of the receiving object. By analyzing the above steps, it can be determined that inter-process communication involves multiple processes, and there is a problem of cross-process object data format compatibility. In addition to simple copying, the custom serialization and deserialization logic in the kernel also has some special cases, so it is necessary to consider how to update the custom logic, and there are security issues in the execution process, and it is necessary to consider preventing the custom serialization and deserialization logic from accessing out of bounds and causing kernel crashes. In addition to the above problems, there are also synchronization issues between the garbage collection (GC) process in the kernel and the sending process, and the garbage collection process in the kernel and the receiving process in the serialization-free communication technology.

[0033] The above two specific serialization-free communication technologies are applicable to a wide range of scenarios, can eliminate serialization / deserialization overhead, and greatly improve communication performance. And the first serialization-free communication method that directly accesses the sending / receiving object through RDMA or TCP connection can solve the synchronization problem between the kernel and the garbage collection process in each process by preventing the memory block where the object to be sent is located from participating in the garbage collection process and preventing the garbage collection process from modifying the receiving object. The second serialization-free communication technology can solve the problem of cross-process object data format compatibility by storing all types of information involved in the transmission process in a dedicated memory space and ensuring that the same information is stored at the same address, and can solve the problem of kernel and process synchronization by pre-deep copying the object to be sent to the dedicated memory space. However, both of the above two serialization-free communication technologies lack support for custom serialization and deserialization logic, and cannot meet the needs of complex communication scenarios such as Android Binder.

[0034] Therefore, in order to solve the problems existing in the serialization-free communication process applied to the inter-process communication scenario, the present application provides a serialization-free communication method, which runs the sandbox program in a programmable sandbox environment through the kernel. In the serialization-free communication process, it supports custom serialization and deserialization logic to meet the needs of complex communication scenarios such as Android Binder. This method is applied to Figure 2 in the system shown.

[0035] like Figure 2 As shown, Figure 22 is a schematic diagram of a mobile terminal system provided by an embodiment of the present application. The mobile terminal system includes multiple processes such as process 210 and process 220 and a kernel 230, and multiple processes communicate with each other through a shared kernel.

[0036] In a specific implementation, each of the multiple processes such as process 210 and process 220 includes a system framework and a language virtual machine, wherein the system framework includes a process control block, program code, data, and security and permission information to manage and control the execution of the process, and the language virtual machine is used to translate the high-level programming language code into machine code and execute it, and can provide garbage collection, exception handling and other functions. Commonly used language virtual machines include Java virtual machines (Java virtual machine, JVM), JavaScript engines, etc. In the embodiment provided in the present application, the system framework also includes a serialization-free communication adapter, which is used to transform the serialization / deserialization code of the native inter-process communication interface, and then adapt to serialization-free communication. The language virtual machine also includes a virtual machine serialization-free memory block manager, which is used to collaborate with the kernel to manage the heap space of the language virtual machine.

[0037] In a specific implementation, the kernel is the core of a computer operating system, which is used to manage computer hardware and provide system services to execute processes. In the embodiment provided in the present application, the kernel also includes a programmable sandbox and a kernel serialization-free memory block manager, wherein the programmable sandbox is used to execute the runtime environment of the injected sandbox program (i.e., custom serialization / deserialization logic), such as the runtime environment of the extended Berkeley packet filter (eBPF), etc., to achieve the expansion of kernel functions, ensure the security of the system, and prevent the occurrence of out-of-bounds access to custom serialization and deserialization logic, resulting in kernel crashes, etc. The kernel serialization-free memory block manager is used to manage the heap space of the language virtual machine together with the language virtual machine.

[0038] In a possible implementation, when process 210 is a sending process and process 220 is a receiving process, process 220 dynamically registers a non-serialized memory block with a kernel non-serialized memory block manager through a corresponding virtual machine non-serialized memory block manager, or releases a previously registered non-serialized memory block; process 210 obtains an original memory address and metadata of a first object to be sent through a corresponding language virtual machine, and then sends the original memory address and metadata of the first object to the kernel through a corresponding non-serialized communication adapter; the kernel is used to run a first sandbox program in a programmable sandbox environment, convert the received original memory address and metadata of the first object into first data, and store it in a first buffer in a non-serialized memory block pre-registered by process 220, wherein the first sandbox program is determined by matching from a plurality of loaded sandbox programs based on the metadata of the first object; the kernel is also used to send the first data at the first address of the first buffer to process 220, so that process 220 converts the first data at the first address of the first buffer into a second object through a corresponding language virtual machine, and provides it to a corresponding system framework for use. When process 210 is a receiving end process and process 220 is a sending end process, the specific process is similar to the above content and will not be described in detail here.

[0039] In addition to the above, the kernel also includes inter-process communication modules, and the process also includes inter-process communication call library modules. Figure 2 This is only a possible implementation of the embodiment of the present application. In actual applications, the above mobile terminal system may also include more or fewer components, which is not limited here.

[0040] In a specific implementation, a mobile terminal system is a communication device running multiple processes, such as a mobile phone, a tablet computer, a desktop computer, etc. Figure 2 The software part is shown in the figure, and the hardware structure is as follows Figure 3 As shown, Figure 3 This is a schematic diagram of the structure of a communication device provided by the present application. The communication device can be applied to Figure 1 In the system shown, the communication device 300 includes: a processor 310, a memory 320, a communication interface 330 and a bus 340, wherein the processor, the memory and the communication interface may be connected via the bus.

[0041] The processor 310 may be composed of at least one general-purpose processor, such as a central processing unit (CPU), or a combination of a CPU and a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The processor 310 is used to execute various types of digital storage instructions.

[0042] The memory 320 may be a volatile memory, such as a random access memory (RAM), a dynamic RAM (DRAM), a static RAM (SRAM), a synchronous dynamic RAM (SDRAM), a double data rate RAM (DDR), a cache, etc. The memory may also include a combination of the above types. The memory 320 includes program code, and the processor 310 can implement all the steps corresponding to the above kernel and process by executing the program code, and realize serialization-free communication between processes.

[0043] The bus 340 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 3 The bus is represented by only one line, but it does not mean that there is only one bus or one type of bus. The bus 340 may include a path for transmitting information between various components of the communication device 300 (eg, the processor 310, the memory 320, and the communication interface 330).

[0044] Need to explain, Figure 3This is only one possible implementation of the embodiment of the present application. In actual applications, the communication device may also include more or fewer components, which is not limited here.

[0045] like Figure 4 As shown, Figure 4 is a flowchart of a serialization-free communication method provided in an embodiment of the present application, which is applied to Figure 2 In the system shown, the method includes the following steps.

[0046] Step S410: the programmable sandbox in the kernel loads the sandbox program.

[0047] The sandbox program loaded by the programmable sandbox in the kernel is generated by the developer on the server or the debugging mobile terminal using the sandbox program automatic generator based on the memory layout file of each field of the transmission object type and the parsing of the native communication interface serialization / deserialization logic code. Figure 5 As shown, Figure 5 It is a flow chart of a sandbox program generation method provided by an embodiment of the present application. Among them, the memory layout file of each field of the transmission object type can be exported from the mobile terminal, which can be a file in JSON format, including the name of each field, type information, offset compared to the first address of the object and memory usage size, etc. In one possible implementation, the memory layout file is different for different operating system versions or different mobile terminal types, so a new sandbox program needs to be generated. The native communication interface serialization / deserialization logic code is used to provide the path of the native serialization / deserialization related code in the Android source code. In the event of changes, a new sandbox program also needs to be generated. The memory layout file of each field of the transmission object type and the parsing of the native communication interface serialization / deserialization logic code are input into the sandbox program automatic generator to generate the sandbox program.

[0048] like Figure 6 As shown, Figure 6This is a workflow diagram of a sandbox program automatic generator provided by an embodiment of the present application. After the execution of the sandbox program automatic generator begins, the input is read and the legality of the input is verified, wherein the input is the memory layout file of each field of the transmission object type and the native communication interface serialization / deserialization logic code; after verifying that the input is legal, the sandbox program automatic generator analyzes the native communication interface serialization / deserialization logic code, generates an abstract syntax tree, and determines the field list that needs to be copied or specially processed; since the memory layout file includes the name of each field, type information, offset compared to the first address of the object and memory usage size and other information, the sandbox program automatic generator queries the information of the above field list through the memory layout file, thereby determining the custom serialization / deserialization logic, outputting the sandbox program, and ending the execution. The above sandbox program generation method can efficiently and accurately determine the custom serialization / deserialization logic for the corresponding serialization-free communication process.

[0049] When the kernel is started, the programmable sandbox in the kernel loads one or more sandbox programs in the fixed directory of the system, and loads one or more sandbox programs to update the loaded sandbox programs, wherein the updated sandbox program is generated by replacing the loaded sandbox program through the command line update, which can improve development efficiency. The programmable sandbox includes one or more sandbox programs, which is not specifically limited in this application.

[0050] In a possible implementation, when a programmable sandbox loads a sandbox program, it is also necessary to perform a security check on the sandbox program to determine whether there is a dead loop or other situation. If there is a dead loop or other security problem, the injection of the sandbox program is terminated, thereby ensuring the security of the sandbox program. Figure 7 As shown, Figure 7 This is a flow chart of a sandbox program injection provided by an embodiment of the present application. After reading the sandbox program, it is determined whether it passes the security check. If the security check fails, the loading of the sandbox program is terminated. If the security check passes, the sandbox program is loaded to be executed in the subsequent serialization-free communication process.

[0051] The user state loads the custom serialization / deserialization logic into the programmable sandbox in the kernel in the form of a sandbox program, which can introduce the custom serialization / deserialization logic into the serialization-free communication process, thereby meeting the needs of complex communication scenarios. The programmable sandbox can also ensure the secure isolation of the process.

[0052] Step S420: the kernel runs the first sandbox program in the programmable sandbox environment, converts the original memory address and metadata of the first object sent by the first process into first data, and stores the data into the first buffer.

[0053] In a possible implementation, the first process first sends the original memory address and metadata of the first object to the kernel. As a sending process, the first process obtains the original memory address and metadata of the first object to be sent from the heap space of the corresponding language virtual machine, generates an inter-process communication data packet according to the original memory address and metadata of the first object, and writes the inter-process communication data packet into the sending byte stream buffer in the inter-process communication call library. The first process initiates a system call and requests the kernel to send a communication message to the second process at the receiving end, so that the second process registers the non-serialized memory block with the kernel non-serialized memory block manager in the kernel through the non-serialized memory block manager in the corresponding language virtual machine, or releases the previously registered non-serialized memory block.

[0054] The kernel parses the inter-process communication data packet sent in the byte stream buffer, obtains the original memory address and metadata of the first object, and selects a matching first sandbox program from multiple sandbox programs in the programmable sandbox according to the metadata of the first object, such as the type information of the first object. The kernel traverses the first object according to the first sandbox program and the original memory address of the first object to determine the total size of the first object. In the case of reference fields in the process of traversing the first object, a deep traversal is required to take the size of the sub-object into account in the total size of the first object. After the first sandbox program determines the total size of the first object, it accesses the interface of the kernel's non-serialized memory block manager and passes in the total size of the first object to determine the size of the first buffer allocated in the pre-registered non-serialized memory block, thereby achieving reasonable and effective allocation of memory blocks and improving utilization.

[0055] The kernel runs the first sandbox program in a programmable sandbox environment, and there are multiple situations in the process of converting the original memory address and metadata of the first object sent by the first process into the first data. In a possible implementation, the first sandbox program traverses the first object again according to the original memory address of the first object, and when it is determined that the field in the first object is a common type field, the common type field is directly copied to the first buffer without conversion, wherein the common type field can be an integer, a string, etc.

[0056] In another possible implementation, when it is determined that a field in the first object is a reference type field, the first sandbox program needs to perform reference repair on the field, determine a new reference field, and copy the new reference field to the first buffer, thereby ensuring that the reference points to the new object, wherein the reference field stores references to other objects and is used to establish a connection relationship between objects. In the above reference repair process, the first sandbox program calculates the size of the first object itself (excluding the size of the referenced sub-object) to calculate the offset in the reference repair, thereby determining the address of the new object in the first buffer.

[0057] In another possible implementation, when the field in the first object is a type field and is different from the type field registered by the second process in the kernel, the first sandbox program performs type repair and stores the new address of the second process corresponding to the type in the first buffer. In the above type repair process, the first sandbox program determines the type of the object that the second process needs to create based on the type field in the first object, allocates space for the new object in the memory based on the determined type information, obtains the memory address of the new object and writes it into the first buffer.

[0058] In summary, the first data includes one or more of a new object, an unprocessed ordinary type field, a new reference type field after special processing, and a new address of the corresponding type of the second process, and this application does not make specific limitations on this. In the above process, the first sandbox program copies the useful field to the buffer, or processes the original field and writes it to the first buffer, which can ensure that in the subsequent serialization-free communication process, the second process reads the correct object and implements support for custom serialization and deserialization logic.

[0059] The kernel executes sandbox programs in a programmable sandbox, that is, custom serialization and deserialization logic, which can isolate the sandbox program and prevent the custom serialization and deserialization logic from accessing beyond the boundaries and causing kernel crashes, thereby ensuring the security of the process and the kernel. It can also implement the serialization-free communication mechanism in complex scenarios with custom serialization / deserialization logic.

[0060] In a possible implementation, during the initialization and execution of the above-mentioned serialization-free communication, the virtual machine serialization-free memory block manager and the kernel serialization-free memory block manager jointly manage the memory blocks used for serialization-free copying. In addition to registering the serialization-free memory block with the kernel serialization-free memory block manager, the virtual machine serialization-free memory block manager in the second process also registers the address of the first metadata with the kernel serialization-free memory block manager to realize message communication between the kernel and the second process. Among them, the kernel records the first address and length of the registered serialization-free memory block, and the first metadata is the data reserved by the second process in the language virtual machine, which is used to record the usage of the serialization-free memory block, including the memory block status, memory block size, memory block owner, usage, and metadata version, etc. This application does not make specific restrictions on this. The kernel updates the first metadata before the end of each serialization-free communication between processes. After the serialization-free communication ends, the second process determines that the serialization-free memory block cannot continue to write data based on the first metadata, and then initiates an asynchronous task. This asynchronous task is used to perform the registration and cleanup of the non-serialized memory blocks. The second process registers new non-serialized memory blocks with the kernel non-serialized memory block manager and moves the non-serialized memory blocks that can no longer write data into the list to be cleaned. In the absence of a garbage collection process, the second process removes the non-serialized mark of the non-serialized memory blocks in the list to be cleaned, and then clears the list to be cleaned, so that the memory blocks with the non-serialized mark removed can be cleaned up when the garbage collection process is executed next time. The above content is the specific process of the memory co-management mechanism of the language virtual machine in the kernel and the process, which can ensure that there are always non-serialized memory blocks in the kernel where new data can be written, so that the kernel has the ability to generate new objects.

[0061] In one possible implementation, since different versions of applications or different programming languages ​​correspond to different type fields, during the process of traversing the first object, the kernel verifies the type security and verifies whether the various type fields of the new object match the type information pre-registered in the kernel by the second process, thereby preventing the language virtual machine corresponding to the second process from running into errors and ensuring the security of communication.

[0062] In a possible implementation, if a sufficiently large buffer cannot be allocated during the above process, or if the type safety check fails, the inter-process communication is interrupted and the data is automatically retransmitted in the mobile terminal system to ensure data integrity and availability.

[0063] Step S430: the kernel sends the first address of the first data in the first buffer to the second process, so that the second process determines the second object according to the first address of the first data in the first buffer.

[0064] After the kernel writes the determined new object and other first data into the first buffer through the first sandbox program and the original memory address and metadata of the first object sent by the first process, and determines that the type field of the new object passes the type safety check, the kernel sends the first address of the first data in the first buffer to the second process, that is, the kernel writes the first address of the first data in the first buffer to the receiving byte stream buffer in the inter-process communication call library of the second process through the inter-process communication module. The language virtual machine in the second process reads the new object address and metadata written by the kernel in the receiving byte stream buffer, and converts the new object address and metadata into the second object according to the modified object generation process, wherein the second object is a common managed language object, which can be used by the system framework of the second process through the serialization-free communication adapter corresponding to the second process, and completes this inter-process communication.

[0065] To sum up, a serialization-free communication method provided in an embodiment of the present application can support custom serialization and deserialization logic in the serialization-free communication process by running a sandbox program (i.e., custom serialization and deserialization logic) in a programmable sandbox environment through the kernel, and meet the needs of complex communication scenarios such as Android Binder. The method provided in the present application realizes the sinking of custom serialization and deserialization logic into the kernel, thereby ensuring the security of the kernel.

[0066] In addition to the above specific inter-process communication steps, in the process of serialization-free communication, since the objects to be sent in the sending process will be modified by the garbage collection process, errors may occur during the copying of the sandbox program, resulting in communication failure or data anomalies. Therefore, the synchronization between the sending process and the kernel also needs to be considered.

[0067] In a possible implementation, the sending end process achieves synchronization between the sending end process and the kernel by preventing the sending end language virtual machine from performing garbage collection during the serialization-free communication process. Figure 8 As shown, Figure 8 This is a schematic diagram of a process of synchronization between a sending end process and a kernel provided by an embodiment of the present application. The synchronization mechanism includes the following steps.

[0068] Step S810: Initiate inter-process communication.

[0069] Step S820: Determine whether GC is being executed.

[0070] In the case that there is a GC being executed, wait for the GC to end and re-judge until it is determined that there is no GC being executed, or return to the native communication process, which is not specifically limited in this application.

[0071] When the garbage collection status is first determined or re-determined and it is determined that no GC is being executed, step S830 is executed.

[0072] Step S830: The sending process holds the GC lock.

[0073] The sending process acquires the GC lock and continues to hold the GC lock, thereby preventing the execution of garbage collection.

[0074] Step S840: Execute serialization-free communication operation.

[0075] When the sending process holds the GC lock, the sending process continues to execute the relevant steps of serialization-free communication.

[0076] Step S850: The sending process releases the GC lock.

[0077] When the serialization-free communication ends, the sending process releases the GC lock so that the language virtual machine of the sending process starts to execute the garbage collection process normally.

[0078] In another possible implementation, the sending end process marks the object to be sent in the language virtual machine in the sending end process during the serialization-free communication to prevent the object to be sent from participating in the garbage collection process. When there is a reference field in the object to be sent, the language virtual machine marks the object pointed to by the reference field in the same way to prevent the object pointed to by the reference field from participating in the garbage collection process.

[0079] Since the above method has a great impact on preventing the execution of the garbage collection process, the present application provides another way to synchronize the sending end process with the kernel. When the language virtual machine in the sending end process is the Java language virtual machine in the Android system, the ART (android runtime) virtual machine, a more efficient garbage collection algorithm is introduced in the ART virtual machine, such as generational garbage collection, Copying GC. Copying GC focuses on the garbage collection of Java heap space memory. By dividing the Java heap space memory into source space (From space) and target space (To space), these two spaces are flipped before each GC starts. During the execution of GC, garbage objects are not directly recycled, but useful objects are copied from From space to Tospace, and then all From spaces are cleaned up when GC is about to end, thereby realizing garbage collection of Java heap space. According to the above process, it can be determined that the objects to be recycled will only be cleaned up in the recycling phase (Reclaim Phase) at the end of GC. Therefore, the present application realizes the synchronization between the kernel and the ART virtual machine by a delayed Reclaim method. In this process, as long as the Reclaim Phase is not executed, even if the object to be recycled is accessed, there will be no access error.

[0080] Fig. 9 is a schematic diagram of the time relationship between a serialization-free communication and GC provided in an embodiment of the present application, such as Fig. 9 As shown, in a possible implementation, when the language virtual machine in the sending end process is an ART virtual machine and all GCs executed are of the Copying GC type, since GC1 and GC2 do not overlap in time with the serialization-free communication process, they will not have any impact on the serialization-free communication process. Although GC3 overlaps with the serialization-free communication time, it will not have any impact because the Reclaim Phase occurs after the serialization-free communication ends. However, the Reclaim Phase of GC4 may occur during the serialization-free communication process, and the Reclaim Phase of GC5 must occur during the serialization-free communication process. Therefore, GC4 and GC5 may clean up or modify the objects to be sent in the sending end process, resulting in errors during the copy of the sandbox program, causing communication failures or data anomalies. The above example can determine that as long as the Reclaim Phase is not executed during the serialization-free communication process, the synchronization between the sending end process and the kernel can be achieved.

[0081] The sending process pre-sets two global count values ​​cnt1 and cnt2, and a global count address cntAddress, which can be the memory address of cnt1 or cnt2. At the beginning of each serialization-free communication, the serialization-free communication thread records the address cntAddressLocal of cntAddress, increases the global count value corresponding to cntAddressLocal by one, and decreases the global count value corresponding to cntAddressLocal by one at the end of the communication. Before each ReclaimPhase starts, the GC thread records the old global count value address cntAddressPrevious and assigns the address of another global count value to cntAddress. The old cntAddressPrevious in the above process is used to indicate that the serialization-free communication thread is still using the objects that may be recycled in this garbage collection. The objects used by the serialization-free communication thread that starts after the address of another global count value is assigned to cntAddress are not considered within the scope of this garbage collection. The garbage collection process waits for the count value pointed to by cntAddressPrevious to become 0 before starting to run ReclaimPhase. At the end of each non-serialized communication, the non-serialized communication sender thread can also check whether the count value pointed to by cntAddressLocal becomes 0. If it is 0, the GC thread is notified through a semaphore. If the GC thread is waiting for the count value to return to 0 before the Reclaim Phase, it will exit the waiting state and execute the Reclaim Phase.

[0082] In a specific embodiment, Fig.10 As shown, Fig.10This is a schematic diagram of a delayed Reclaim process provided by an embodiment of the present application. During the execution of GC1, before the Reclaim Phase begins, GC1 records the old global count value address cntAddressPrevious, where cntAddressPrevious is the memory address of cnt1, and assigns the memory address of cnt2 to cntAddress. Before GC1 assigns the memory address of cnt2 to cntAddress, the serialization-free thread 1 and the serialization-free thread 2 have already started executing. Therefore, GC1 needs to wait until the serialization-free thread 2 ends before starting the recovery phase. Specifically, when the serialization-free thread 1 starts, the serialization-free thread 1 determines that cntAddressLocal is the memory address of cnt1 at this time, adds 1 to cnt1, and determines that the global count value cnt1 = 1. Then the serialization-free thread 2 starts, and continues to add 1 on the basis of cnt1 plus 1, and the global count value cnt1 = 2. Then the serialization-free thread 1 ends, and subtracts 1 from cnt1 to determine that the global count value cnt1 = 1. Then the serialization-free thread 2 ends, and subtracts 1 from cnt1 to determine that the global count value cnt1 = 0. At this time, the global count value pointed to by cntAddressLocal is 0, that is, cnt1 is 0, and GC1 is notified to start executing ReclaimPhase. In the subsequent process, before GC2 assigns the memory address of cnt1 to cntAddress, the serialization-free thread 3 and the serialization-free thread 4 whose cntAddressLocal is the memory address of cnt2 have already started to execute. Therefore, the ReclaimPhase of GC2 needs to wait until the serialization-free thread 3 and the serialization-free thread 4 are finished before starting to execute, that is, wait until cnt2 is 0 to start recycling. The specific process is similar to the above process, and this application will not repeat it here. Similarly, the objects used by the serialization-free thread 5 need to wait until the garbage collection thread executed after GC2 is recycled. The above method can realize the execution of the recovery phase of delayed garbage collection, thereby ensuring the synchronization of the process and the kernel.

[0083] In order to ensure the synchronization between the sending end process and the kernel, in addition to delaying the Reclaim Phase, it is also necessary to consider the problem of new object allocation during the garbage collection process. The allocation of new objects may cause distortion of old data. In a specific implementation, Fig. 9As shown, the GC4 execution interval overlaps with the serialization-free communication process. In the GC4 execution interval, a new object is allocated. Initially, Object-A has a reference field b, which is null. During the communication process, a thread allocates a new object Object-B and sets the reference of Object-Ab to the address of the new object Object-B, thereby modifying the data of the object Object-A to be sent. At the same time, the ongoing serialization-free communication process may access the old object before the modification when accessing Object-A, that is, Object-Ab is null.

[0084] In order to solve the above problems, the present application provides another way to synchronize the sending end process with the kernel. By following the To space invariant method in the serialization-free communication process, it is realized that during the execution of GC, only objects in the Tospace can be accessed by the serialization-free communication process, and objects in the From space are considered invalid or inaccessible. In the process of accessing objects in the To space, if there is a forwarding pointer (Forwardingpointer) in the referenced object, the new object stored in the Forwarding pointer is preferentially accessed, wherein the Forwardingpointer is a technology used to track object movement and redirect references in garbage collection, and by leaving a Forwarding pointer including the address of the new object in the metadata in the To space, it is ensured that the objects finally accessed by the upper-level code are all new objects. In a specific implementation, the above modification of the data of Object-A is used as an example for explanation. In the process of accessing Object-A in the To space space, the referenced object has a Forwarding pointer, and the Forwarding pointer points to the address of the new object Object-B, thereby realizing the allocation of the new object in time, and in the process of serialization-free communication, only the new object will be accessed. In the above process, when the old Object-Ab is not null and is the address of Object-C, after the new object is allocated, the garbage collection process retains the address of Object-C in Fromspace and finally recycles it.

[0085] In addition to considering the synchronization problem between the sending process and the kernel, the synchronization mechanism between the receiving process and the kernel also needs to be considered because the receiving process pre-registered in the kernel during the non-serialization communication may not be used for memory allocation or be recycled by the garbage collection process. The synchronization between the receiving process and the kernel can be solved by marking the non-serialization memory blocks registered in the kernel. The non-serialization memory blocks with the non-serialization mark can avoid being recycled by the garbage collection process, but the receiving garbage collection process can access the objects on the non-serialization memory blocks to complete the garbage collection scan, thereby avoiding the problem of missing scans and recycling useful fields.

[0086] In one possible implementation, when a reference field of object A on a non-serializable memory block points to object B, and object B is on a normal memory block, the garbage collection process continues to scan object B after scanning object A, and also marks object B as a useful object, thereby avoiding the recycling of object B.

[0087] In a specific embodiment, Fig.11 As shown, Fig.11 It is a schematic diagram of the system structure that supports Binder communication between Java processes for serialization-free communication provided by an embodiment of the present application. Process 1 and process 2 are two Java processes, and Java processes can be application processes or system service processes, which are not specifically limited in this application. The two Java processes each include a Java virtual machine (ART), a binder call library (libbinder) and a system framework, the system framework includes a serialization-free communication adapter module, the Java virtual machine includes a serialization-free memory block manager, and the kernel includes a Binder driver module, a programmable sandbox and a kernel serialization-free memory block manager.

[0088] The user state injects the sandbox program required for this serialization-free communication process into the programmable sandbox. Process 1 initiates inter-process communication, obtains the original memory address and metadata of the sending object in the Java virtual machine, packages the sending object memory address and metadata into a serialization-free inter-process communication data packet, and sends the data packet to the Binder driver module. The Binder driver parses the data packet and selects a matching sandbox program according to the metadata of the sending object. The sandbox program running in the programmable sandbox first traverses the sending object once through the original memory address of the sending object, and accumulates the size of the sub-objects to obtain the total size of the sending object. The sandbox program accesses the interface of the kernel serialization-free memory block manager, passes in the total size of the sending object, and obtains a partial buffer in the heap space of process 2. The sandbox program traverses the sending object again. When encountering a common type field, it directly copies it to the buffer. When encountering a reference type field, it performs reference repair. According to the size of the sending object itself, the offset in the reference repair is calculated, thereby determining the address of the new object in the buffer, and storing it as a new reference field in the allocated partial buffer; when encountering a type field, it performs type repair and writes the address of the corresponding type of process 2 into the allocated partial buffer. After that, a type safety check is performed. If the safety check passes, the first address of the buffer is written into the buffer in libbinder of process 2 through the Binder driver. The ART of process 2 reads the receiving object address and metadata in the data packet received between the serialization-free communication processes, and uses the modified object generation process to convert the receiving object address and metadata into a common Java object, so that the system framework can receive and use it through the serialization-free communication adapter.

[0089] The present application also provides a computer program product including instructions. The computer program product may be a software or program product including instructions that can be run on a communication device or stored in any available medium. When the computer program product is run on a communication device, the communication device is enabled to execute Figure 4 The serialization-free communication method shown.

[0090] The present application also provides a computer-readable storage medium. The computer-readable storage medium may be any available medium that can be stored by a communication device or a data communication device such as a data center that includes one or more available media. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk). The computer-readable storage medium includes instructions that instruct the communication device to execute Figure 4 The serialization-free communication method shown.

[0091] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

Claims

1. A mobile terminal system, characterized in that: The system includes multiple processes, and the multiple processes communicate with each other through a common kernel: The kernel is used to run a first sandbox program in a programmable sandbox environment, determine first data according to an original memory address and metadata of a first object sent by a first process, and store the first data in a first buffer, wherein the first sandbox program is determined by matching a plurality of sandbox programs according to the metadata of the first object, and the first buffer is a part of a serialization-free memory block registered by a second process with the kernel; The kernel is further used to send the first data at the first buffer address to the second process, so that the second process determines a second object according to the first data at the first buffer address, and the second object is applicable to the second process.

2. The system according to claim 1, characterized in that The programmable sandbox includes one or more sandbox programs loaded into a system fixed directory, and one or more sandbox programs for updating the loaded sandbox programs. Each of the one or more sandbox programs is generated according to the serialization and deserialization logic of process communication.

3. The system according to claim 1 or 2, characterized in that: The kernel is specifically used for: According to the first sandbox program and the original memory address of the first object, traverse the first object, determine the total size of the first object, and determine the size of the first buffer, wherein the total size of the first object includes the size of the first object and the size of the sub-object referenced by the first object; Running the first sandbox program in the programmable sandbox environment, and determining the first data according to the original memory address and metadata of the first object sent by the first process; The first data is stored in the first buffer.

4. The system according to claim 3, characterized in that: The kernel is specifically used for: If the field in the first object is a common type field, storing the common type field as the first data in the first buffer; If the field in the first object is a reference type field, perform reference repair according to the first sandbox program and the size of the first object, determine a new reference field, and store the new reference field as the first data in the first buffer; When the field in the first object is a type field and is different from the type field of the second process registered in the kernel, a new address of the type corresponding to the second process is stored in the first buffer as the first data, and the type corresponding to the second process is determined based on the type field in the first object.

5. The system according to claim 4, characterized in that Before the kernel is used to run a first sandbox program in a programmable sandbox environment, the second process is used to: The address of the first metadata and the serialization-free memory block including the serialization-free mark are registered with the kernel, wherein the first metadata is used to record the usage of the serialization-free memory block and is updated by the kernel.

6. The system according to claim 5, characterized in that The second process is also used to: When it is determined according to the first metadata that the serialization-free memory block no longer writes data, a new serialization-free memory block is registered, and the serialization-free mark corresponding to the serialization-free memory block is removed, so that the serialization-free memory block is reclaimed by the garbage collection process in the second process.

7. The system according to any one of claims 4 to 6, characterized in that: The first process is also used to: Preventing the execution of the garbage collection process in the first process, or delaying the execution of the collection phase of the garbage collection process in the first process.

8. A serialization-free communication method, characterized in that: Applied to a mobile terminal system, wherein a plurality of processes sharing a common kernel are running in the mobile terminal system, and the plurality of processes communicate with each other through the kernel, the method comprising: The kernel runs a first sandbox program in a programmable sandbox environment, determines first data according to an original memory address and metadata of a first object sent by a first process, and stores the first data in a first buffer, wherein the first sandbox program is determined by matching a plurality of sandbox programs according to the metadata of the first object, and the first buffer is a part of a serialization-free memory block registered by a second process with the kernel; The kernel sends the first data at the first address of the first buffer to the second process, so that the second process determines a second object according to the first address of the first data in the first buffer, and the second object is applicable to the second process.

9. A communication device, characterized in that: The communication device comprises a processor and a memory, wherein the processor is configured to execute instructions stored in the memory of the communication device, so that the communication device performs the method according to claim 8.

10. A computer program product comprising instructions, characterized in that When the instructions are executed by a communication device, the communication device is caused to perform the method according to claim 8.

11. A computer-readable storage medium, characterized in that: The method comprises computer program instructions, which, when executed by a communication device, cause the communication device to perform the method according to claim 8.

Images