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

Abstract

Disclosed in the present application are a serialization-free communication method, a system and a computer-readable storage medium. The serialization-free communication method is applied for a mobile terminal system, the system comprising a plurality of processes, and the plurality of processes performing communication via a common kernel. The kernel is used for running in a programmable sandbox environment a first sandbox program, converting into first data an original memory address and metadata of a first object which are sent by the first process, and storing same into a first buffer area, the first sandbox program being determined by means of matching from a plurality of sandbox programs on the basis of the metadata of the first object; and sending a first address of the first data in the first buffer area to a second process, so as to enable the second process to determine a second object on the basis of the first address of the first data in the first buffer area. By means of running in programmable sandbox environments sandbox programs, the serialization-free communication method is applicable for complex communication scenarios where customized serialization and deserialization logics are present, thus ensuring the security of communication processes and kernels.

Description

A serialization-free communication method, system, and computer-readable storage medium

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on September 25, 2023, with application number 202311266052.9 and application name “A Serialization-Free Communication Method, System and Computer-Readable Storage Medium”, the entire contents of which are incorporated by reference into this application. Technical Field

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

[0003] Currently, to improve communication performance and reduce the significant serialization / deserialization overhead during inter-process communication, various solutions exist, such as reducing the amount of data transmitted and employing caching mechanisms. However, these approaches are limited in their applicability, leading to the development of serialization-free communication technologies. One such technology allows Java applications to directly access send and receive objects via remote direct memory access (RDMA) or transmission control protocol (TCP) connections.

[0004] However, the above method can only send the object to be sent in its entirety. 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.

[0005] Summary of the Invention

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

[0007] In a first aspect, the present application provides a mobile terminal system comprising multiple processes that communicate with each other through a shared kernel. The kernel is configured to run a first sandbox program in a programmable sandbox environment, determine first data based on the original memory address and metadata of a first object sent by the first process, and store the first data in a first buffer, wherein the first sandbox program is determined by matching multiple sandbox programs based on the metadata of the first object, and the first buffer is a portion of a non-serialized memory block registered by a second process with the kernel; the kernel is further configured to send the first data at the first address of the first buffer to the second process, so that the second process determines a second object based on the first address of the first data at the first buffer, and the second object is applicable to the second process.

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

[0009] In one possible embodiment, a programmable sandbox includes one or more sandbox programs loaded into a fixed system directory, as well as one or more sandbox programs that update the loaded sandbox programs. Each of the one or more sandbox programs is generated based on the serialization and deserialization logic of process communication. The sandbox program is generated based on the serialization and deserialization logic of process communication and the memory layout file of the first object. After being injected into the programmable sandbox, the serialization-free communication method can be applied in complex communication scenarios with custom serialization and deserialization logic. The programmable sandbox can also isolate the sandbox program to prevent kernel attacks and ensure security. The above-mentioned updating of the loaded sandbox program can improve development efficiency. Specifically, the loaded sandbox program can be updated through the command line. The one or more sandbox programs injected into the programmable sandbox are all security-checked. For example, a determination is made as to whether the sandbox program has a dead loop or other conditions. If a dead loop or other conditions exist, the sandbox program is not injected into the programmable sandbox, thereby ensuring the normal operation of the subsequent serialization-free communication process.

[0010] In one possible implementation, the kernel is specifically configured to, based on a 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 a first buffer, where the total size of the first object includes the size of the first object and the sizes of sub-objects referenced by the first object; run the first sandbox program in a programmable sandbox environment, determine first data based on 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 an appropriate 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 kernel.

[0011] In one possible embodiment, the kernel is specifically configured to: if a field in a first object is a common type field, store the common type field as first data in a first buffer; if a field in the first object is a reference type field, perform reference repair based on the first sandbox program and the size of the first object, determine a new reference field, and store the new reference field as first data in the first buffer; if a field in the first object is a type field and is different from the type field registered with the kernel by a second process, store a new address of the type corresponding to the second process as first data in the first buffer, where the type corresponding to the second process is determined based on 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 based on 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.

[0012] 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 marks the serialization-free memory block registered with the kernel as serialization-free, so that the serialization-free memory block will not be used by the second process for memory allocation during the serialization-free communication process and will not be 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 is always an available serialization-free memory block in the kernel to write new data determined according to the object to be sent.

[0013] In one possible embodiment, the second process is further configured to: register a new non-serialized memory block when it is determined based on the first metadata that no data is written to the non-serialized memory block, remove the non-serialized mark corresponding to the non-serialized memory block, so that the non-serialized memory block can be recycled by the garbage collection (GC) process in the second process. The first metadata registered by the second process with the kernel may include size information of each memory block, status information of the memory block (e.g., whether the memory block is allocated or unallocated), and information about the process assigned to the memory block. 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 subsequent communication processes based on the updated first metadata. Thus, when the non-serialized memory block is no longer written to, register a new non-serialized memory block with the kernel, move the non-serialized memory block to 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 performed.

[0014] In one possible implementation, the first process is further configured to: prevent execution of a garbage collection process within the first process, or to delay execution of a recovery phase within the garbage collection process within the first process. The aforementioned process can implement a synchronization mechanism between the first process and the kernel during serialization-free communication, thereby ensuring that objects to be sent are not destroyed by the garbage collection process. For specific types of garbage collection processes (e.g., copying garbage collection), delaying the recovery phase can reduce overhead compared to preventing the garbage collection process.

[0015] In a second aspect, the present application provides a serialization-free communication method, which is applied to the mobile terminal system described in the first aspect, wherein multiple processes running on a common kernel communicate with each other through the kernel. The method comprises: the kernel runs a first sandbox program in a programmable sandbox environment, converts the original memory address and metadata of a first object sent by the first process into first data, and stores the data in a first buffer, wherein the first sandbox program is determined by matching 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 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 the second object based on the first address of the first data at the first buffer, and the second object is applicable to the second process.

[0016] In a third aspect, the present application provides a communication device that runs the mobile terminal system provided in the first aspect. The communication device includes a processor and a memory. 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 above-mentioned second aspect.

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

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

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

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

[0021] FIG1 is a schematic diagram of a serialization-free communication process in an inter-process communication scenario provided by an embodiment of the present application;

[0022] FIG2 is a schematic structural diagram of a mobile terminal system provided in an embodiment of the present application;

[0023] FIG3 is a schematic structural diagram of a communication device provided in an embodiment of the present application;

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

[0025] FIG5 is a flowchart of a sandbox program generation method provided by an embodiment of the present application;

[0026] FIG6 is a flowchart of a sandbox program automatic generator provided in an embodiment of the present application;

[0027] FIG7 is a flow chart of a sandbox program injection provided by an embodiment of the present application;

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

[0029] FIG9 is a schematic diagram of the time relationship between serialization-free communication and GC provided in an embodiment of the present application;

[0030] FIG10 is a schematic diagram of a delayed Reclaim process provided by an embodiment of the present application;

[0031] FIG11 is a schematic diagram of a system structure supporting serialization-free communication by Binder communication between Java processes provided by an embodiment of the present application. DETAILED DESCRIPTION

[0032] Currently, serialization / deserialization overhead accounts for a significant portion of the total overhead of binder communication, impacting communication performance. To reduce serialization / deserialization overhead during inter-process communication, various improvements can be implemented, such as reducing the amount of data transmitted or implementing caching mechanisms. Among these, reducing the amount of data transmitted involves agreeing on transmission rules, such as sending only one copy of redundant fields, omitting field types, or performing data compression. This reduces overhead by reducing the amount of data involved in serialization / deserialization. However, this approach is only suitable for scenarios with high amounts of redundant data or high transmission latency. Caching, on the other hand, caches call results on the sending end for direct use in the next call if the result is the same. This approach is also only applicable in scenarios where inter-process communication call results rarely change, and caching requires additional memory. To address the shortcomings of these improvements, a serialization-free communication technology has been proposed.

[0033] Among them, one serialization-free communication technology enables applications to directly access the sending / receiving objects and their metadata 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. However, if the serialization / deserialization logic involves special processing in addition to simple field copying (for example, the object to be sent defines its own corresponding serialization / deserialization logic, in which certain fields are not serialized / deserialized, or certain repeated fields are serialized / deserialized only once), this custom serialization / deserialization logic cannot be supported during the serialization-free communication process, and cannot meet the requirements of complex communication scenarios such as Android Binder. In another serialization-free communication technology, the sending process and the receiving process each pre-allocate a dedicated memory space with a completely identical memory layout for serialization-free communication. All type information involved in serialization-free transmission is stored in a memory space similar to distributed shared memory, ensuring that the memory addresses where the information is stored are completely consistent, enabling direct reading and writing of objects, thereby avoiding the problem of sending objects causing changes to object addresses and type addresses, requiring type repair and reference repair. However, this method can only achieve simple copying of objects and cannot implement 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.

[0034] In addition to the two specific serialization-free communication technologies mentioned above, an embodiment of the present application provides a process diagram of serialization-free communication in an inter-process communication scenario, as shown in Figure 1. According to Figure 1, it can be determined that serialization-free communication includes the following multiple 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 based on 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. It is necessary to consider preventing the custom serialization and deserialization logic from having out-of-bounds access, resulting in kernel crashes, etc. In addition to the above problems, the serialization-free communication technology also has the problem of synchronizing the garbage collection (GC) processes in the kernel and the sending process, and the garbage collection processes in the kernel and the receiving process.

[0035] 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. In addition, 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. It can also solve the problem of kernel and process synchronization by pre-deep copying the object to be sent to a 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.

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

[0037] As shown in Figure 2, which is a schematic diagram of the structure 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 the multiple processes communicate with each other through a shared kernel.

[0038] 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. 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 (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.

[0039] In a specific implementation, the kernel is the core of a computer operating system, used to manage computer hardware and provide system services to execute processes. In the embodiments provided in this application, the kernel also includes a programmable sandbox and a kernel serialization-free memory block manager. 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), to expand kernel functions, ensure system security, and prevent out-of-bounds access in custom serialization and deserialization logic, leading to kernel crashes. 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.

[0040] In one 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 the kernel non-serialized memory block manager through the corresponding virtual machine non-serialized memory block manager, or releases a previously registered non-serialized memory block; process 210 obtains the original memory address and metadata of the first object to be sent through the corresponding language virtual machine, and then sends the original memory address and metadata of the first object to the kernel through the 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 the non-serialized memory block pre-registered by process 220, wherein the first sandbox program is determined by matching from multiple loaded sandbox programs based on the metadata of the first object; the kernel is also used to send the first address of the first data in 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 the corresponding language virtual machine, and provides it to the corresponding system framework for use. In the case where 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.

[0041] In addition to the above, the kernel also includes an inter-process communication module, etc., and the process also includes an inter-process communication call library module, etc. It should be noted that Figure 2 is only one 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.

[0042] In a specific implementation, the mobile terminal system is a communication device running multiple processes, such as a mobile phone, a tablet computer, a desktop computer, etc. In addition to the software part shown in Figure 2, the hardware structure is shown in Figure 3. Figure 3 is a structural diagram of a communication device provided in this application. The communication device can be applied to the system shown in Figure 1. The communication device 300 includes: a processor 310, a memory 320, a communication interface 330 and a bus 340, wherein the processor, memory, and communication interface can be connected through a bus.

[0043] 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 configured to execute various types of digital storage instructions.

[0044] Memory 320 can be volatile memory, such as random access memory (RAM), dynamic RAM (DRAM), static RAM (SRAM), synchronous dynamic RAM (SDRAM), double data rate RAM (DDR), cache, etc. Memory can also include a combination of the above. Memory 320 includes program code, and processor 310 executes this program code to implement all steps corresponding to the kernel and processes described above, enabling serialization-free communication between processes.

[0045] Bus 340 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, among others. Buses may be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG3 illustrates a bus using only one line, but this does not imply that there is only one bus or only one type of bus. Bus 340 may include a path for transmitting information between the various components of communication device 300 (e.g., processor 310, memory 320, and communication interface 330).

[0046] It should be noted that FIG3 is only a possible implementation of an embodiment of the present application. In actual applications, the communication device may also include more or fewer components, which is not limited here.

[0047] As shown in FIG4 , FIG4 is a flowchart of a serialization-free communication method provided in an embodiment of the present application. The method is applied to the system shown in FIG2 , and the method includes the following steps.

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

[0049] The sandbox program loaded by the programmable sandbox in the kernel is generated by the developer on the server or 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. As shown in Figure 5, Figure 5 is a flowchart 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 and can be a file in JSON format, including the name of each field, type information, offset compared to the object's first address and memory usage size, etc. In one possible embodiment, 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. If there is a change in the native communication interface serialization / deserialization logic code, 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.

[0050] As shown in Figure 6, Figure 6 is a workflow diagram of a sandbox program automatic generator provided by an embodiment of the present application. After the sandbox program automatic generator starts executing, it reads the input and verifies the legality of the input, 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 list of fields that need to be copied or specially processed; since the memory layout file includes the name of each field, type information, offset compared to the object's first address 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 execution. The above sandbox program generation method can efficiently and accurately determine the custom serialization / deserialization logic for the corresponding serialization-free communication process.

[0051] When the kernel is booted, the programmable sandbox in the kernel loads one or more sandbox programs from a fixed system directory, and also loads one or more sandbox programs that update the loaded sandbox programs. The updated sandbox programs are generated by replacing the loaded sandbox programs via command line updates, which can improve development efficiency. The programmable sandbox may include one or more sandbox programs, which is not specifically limited in this application.

[0052] In one 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 are situations such as dead loops. If there are security issues such as dead loops, the injection of the sandbox program is terminated, thereby ensuring the security of the sandbox program. Specifically, as shown in Figure 7, Figure 7 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 for execution in the subsequent serialization-free communication process.

[0053] The user state loads custom serialization / deserialization logic into the kernel's programmable sandbox in the form of a sandbox program. This allows the custom serialization / deserialization logic to be introduced into the serialization-free communication process, thereby meeting the needs of complex communication scenarios. The programmable sandbox can also ensure secure process isolation.

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

[0055] In one possible implementation, a first process first sends the original memory address and metadata of a 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 based on the original memory address and metadata of the first object, and writes the inter-process communication data packet to a send 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 a second process on the receiving end, so that the second process registers a 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 a previously registered non-serialized memory block.

[0056] 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 based on the metadata of the first object, such as the type information of the first object. The kernel traverses the first object based on the first sandbox program and the original memory address of the first object to determine the total size of the first object. If there are reference fields in the process of traversing the first object, a deep traversal is required to take the size of the child object into account in the total size of the first object. After determining the total size of the first object, the first sandbox program 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.

[0057] The kernel runs a first sandbox program in a programmable sandbox environment, and various scenarios may occur during the process of converting the original memory address and metadata of a first object sent by a first process into first data. In one possible implementation, the first sandbox program again traverses the first object based on the original memory address of the first object. If a field in the first object is determined to be a common type field, the common type field is directly copied to the first buffer without conversion. The common type field may be an integer, a string, or the like.

[0058] In another possible implementation, when a field in the first object is determined to be 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. The reference field stores references to other objects and is used to establish a connection relationship between objects. During the 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 used in the reference repair, thereby determining the address of the new object in the first buffer.

[0059] In another possible implementation, if 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, the first sandbox program performs type repair and stores the new address of the corresponding type of the second process in the first buffer. During this type repair process, the first sandbox program determines the type of object to be created by the second process based on the type field in the first object. Based on the determined type information, the first sandbox program allocates space for the new object in memory, obtains the memory address of the new object, and writes it to the first buffer.

[0060] In summary, the first data includes one or more of a new object, an unprocessed field of a common type, a newly processed field of a reference type, and a new address of a corresponding type for the second process, which is not specifically limited in this application. During the above process, the first sandbox program copies the useful fields to the buffer, or processes the original fields and writes them to the first buffer. This ensures that during subsequent serialization-free communication, the second process reads the correct object, thus supporting custom serialization and deserialization logic.

[0061] The kernel executes sandbox programs, that is, custom serialization and deserialization logic, in a programmable sandbox. This can isolate the sandbox programs and prevent kernel crashes caused by out-of-bounds access in custom serialization and deserialization logic, ensuring the security of processes and the kernel. It can also enable the serialization-free communication mechanism to be applied to complex scenarios with custom serialization / deserialization logic.

[0062] In a possible embodiment, 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 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 each serialization-free communication between processes ends. After the serialization-free communication ends, the second process initiates an asynchronous task when it determines that the serialization-free memory block cannot continue to write data based on the first metadata. This asynchronous task is used to perform the registration and cleanup of 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 coordination 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.

[0063] 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 errors in the operation of the language virtual machine corresponding to the second process and ensuring the security of communication.

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

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

[0066] After the kernel writes the determined new object and other first data into the first buffer using the first sandbox program and the original memory address and metadata of the first object sent by the first process, and confirms that the type field of the new object passes the type safety check, the kernel then sends the first address of the first data in the first buffer to the second process. Specifically, the kernel writes the first address of the first data in the first buffer to the receive 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 into the receive byte stream buffer and converts the new object address and metadata into a second object according to the modified object generation process. The second object is a common managed language object that can be used by the system framework of the second process through the serialization-free communication adapter corresponding to the second process, thereby completing this inter-process communication.

[0067] To sum up, the embodiment of the present application provides a serialization-free communication method, which supports custom serialization and deserialization logic during 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 meets the needs of complex communication scenarios such as Android Binder. The method provided by the present application realizes the sinking of custom serialization and deserialization logic into the kernel, thereby ensuring the security of the kernel.

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

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

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

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

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

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

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

[0075] The sending process acquires the GC lock and holds it continuously, thus preventing garbage collection from being performed.

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

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

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

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

[0080] In another possible implementation, the sending process marks the object to be sent in its language virtual machine during serialization-free communication to prevent the object from participating in garbage collection. If the object to be sent contains a reference field, the language virtual machine also marks the object pointed to by the reference field, preventing the object from participating in garbage collection.

[0081] Since the impact of preventing the execution of the garbage collection process in the above method is relatively large, 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, the ART virtual machine introduces a more efficient garbage collection algorithm, 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 To space. 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. During this process, as long as the Reclaim Phase is not executed, even if the objects to be recycled are accessed, no access error will occur.

[0082] FIG9 is a schematic diagram of the time relationship between a serialization-free communication and GC provided by an embodiment of the present application. As shown in FIG9 , 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, thereby causing errors during the copy of the sandbox program, resulting in communication failure 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.

[0083] The sending process pre-sets two global counters, cnt1 and cnt2, and a global counter address, cntAddress, which can be the memory address of either cnt1 or cnt2. At the start of each deserialization-free communication, the deserialization-free communication thread records the address cntAddressLocal of cntAddress and increments the global counter corresponding to cntAddressLocal by one. At the end of the communication, the global counter corresponding to cntAddressLocal is decremented by one. Before each reclaim phase, the garbage collection thread records the old global counter address, cntAddressPrevious, and assigns the address of another global counter to cntAddress. The old cntAddressPrevious in this process indicates that the deserialization-free communication thread is still using objects that may be reclaimed by this garbage collection. Objects used by deserialization-free communication threads started after the address of the other global counter is assigned to cntAddress are not considered for garbage collection. The garbage collection process waits for the counter pointed to by cntAddressPrevious to become 0 before starting the reclaim phase. At the end of each serialization-free communication, the sending thread of the serialization-free communication 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 jump out of the waiting state and execute the Reclaim Phase.

[0084] In a specific embodiment, as shown in Figure 10, Figure 10 is a schematic diagram of a delayed Reclaim process provided by an embodiment of the present application. During the execution of GC1, before the start of the Reclaim Phase, GC1 records the old global count value address cntAddressPrevious, at which time 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 serialization-free thread 1 starts, it 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, serialization-free thread 2 starts and continues to add 1 to the value of cnt1, making the global count value cnt1 = 2. Then, serialization-free thread 1 ends and subtracts 1 from cnt1, making the global count value cnt1 = 1. Then, serialization-free thread 2 ends and subtracts 1 from cnt1, making the global count value cnt1 = 0. At this time, the global count value pointed to by cntAddressLocal is 0, that is, cnt1 is 0, notifying GC1, causing GC1 to start executing the Reclaim Phase. 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 Reclaim Phase of GC2 needs to wait until the serialization-free thread 3 and the serialization-free thread 4 are finished before it starts to execute, that is, it waits until cnt2 is 0 to start recycling. The specific process is similar to the above process and will not be repeated here in this application. 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 recycling phase of delayed garbage collection, thereby ensuring the synchronization of the process and the kernel.

[0085] In order to ensure the synchronization between the sending 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 will cause distortion of old data, etc. In a specific embodiment, as shown in Figure 9, there is a time overlap between the GC4 execution interval and the serialization-free communication process. During the GC4 execution interval, a new object is allocated. Initially, there is a reference field b in Object-A, and b 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, when the ongoing serialization-free communication process accesses Object-A, it may access the old object before the modification, that is, Object-Ab is null.

[0086] 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 achieved that during the execution of GC, only objects in the To space 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 a forwarding pointer exists in the referenced object, the new object stored in the Forwarding pointer is preferentially accessed. The Forwarding pointer is a technology used to track object moves and redirect references in garbage collection. 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 ultimately accessed by the upper-level code are all new objects. In a specific embodiment, the above-mentioned modification of the data of Object-A is used as an example to illustrate. In the process of accessing Object-A in the To space, the referenced object has a Forwarding pointer, and the Forwarding pointer points to the address of the new object Object-B, thereby achieving the timely allocation of the new object. 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 the From space and finally reclaims it.

[0087] In addition to considering synchronization issues between the sending process and the kernel, the synchronization mechanism between the receiving process and the kernel must also be considered because during serialization-free communication, the serialization-free memory blocks pre-registered in the kernel by the receiving process may not be used for memory allocation or reclaimed by the garbage collection process. This synchronization can be achieved by marking the serialization-free memory blocks registered in the kernel as serialization-free. Serialization-free memory blocks marked as serialization-free can avoid being reclaimed by the garbage collection process, but the receiving garbage collection process can access objects in these memory blocks to complete the garbage collection scan, thus avoiding missed scans that can lead to the recovery of useful fields.

[0088] 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 marks object B as a useful object, thereby avoiding the recycling of object B.

[0089] In a specific embodiment, as shown in Figure 11, Figure 11 is a schematic diagram of the system structure for supporting 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. 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.

[0090] User mode 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's memory address and metadata into a serialization-free inter-process communication packet, and sends this packet to the Binder driver module. The Binder driver parses the packet and selects a matching sandbox program based on the sending object's metadata. The sandbox program running in the programmable sandbox first traverses the sending object using its original memory address, accumulating the sizes of its sub-objects to determine its total size. The sandbox program accesses the kernel's serialization-free memory block manager interface, passing in the total size of the sending object, and obtains a partial buffer in Process 2's heap space. The sandbox program traverses the sending object again. When encountering a normal type field, it copies it directly into the buffer. When encountering a reference type field, it performs reference repair, calculating the offset in the reference repair based on the sending object's original size to determine the new object address 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, writing the address of Process 2's corresponding type into the allocated partial buffer. Afterwards, a type safety check is performed. If the check passes, the buffer's starting address is written to the buffer in libbinder in process 2 via the Binder driver. The ART in process 2 reads the receiving object address and metadata from the received data packet from the serialization-free communication process and uses the modified object generation process to convert them into ordinary Java objects, allowing the system framework to receive and use them through the serialization-free communication adapter.

[0091] The present application also provides a computer program product including instructions. The computer program product may be software or a 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 executes the serialization-free communication method shown in FIG4 .

[0092] The embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium can 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 can 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 drive). The computer-readable storage medium includes instructions that instruct the communication device to execute the serialization-free communication method shown in Figure 4.

[0093] 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 deviate the essence of the corresponding technical solutions from the protection scope of the technical solutions of the various 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