Virtual function calling method and apparatus, computing device, storage medium, and program product
By determining the target data type in shared memory and obtaining the virtual function table pointer, the problem of difficult virtual function calls between processes is solved, achieving efficient and flexible virtual function calls while maintaining the integrity and maintainability of objects.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HUAWEI TECH CO LTD
- Filing Date
- 2024-12-03
- Publication Date
- 2026-06-05
Smart Images
Figure CN122152394A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to virtual function calling methods, apparatus, computing devices, storage media, and program products. Background Technology
[0002] In the field of object-oriented programming, virtual functions are an important language feature that helps programs achieve dynamic polymorphism, interface reuse, and other capabilities, improving code reusability, extensibility, and maintainability. Inter-process communication (IPC) is a technique for transferring data between at least two processes. Among these, shared memory is generally considered to be the best performing IPC method. However, because different processes are allocated different address space ranges, a process may not be able to call virtual functions using only the virtual function table pointers stored in shared memory.
[0003] Existing solutions typically employ data splitting or address alignment to transform shared memory scenarios into something similar to non-shared memory scenarios. Virtual function calls are then implemented through the call flow in non-shared memory scenarios. These solutions can easily restrict developers or require extensive customization, and are only applicable to certain specific systems. Summary of the Invention
[0004] This application provides a virtual function calling method, apparatus, computing device, storage medium, and program product. By improving the virtual function calling process in a shared memory scenario, specifically, after the computing device receives a virtual function call request from a first process, it first determines the target data type of the object corresponding to the call request, and then obtains a virtual function table pointer determined according to the address space range of the first process based on the target data type and the first correspondence. This enables the use of the superior performance of shared memory while fully preserving the object's data structure, and allows for normal virtual function calls to take advantage of the various characteristics of virtual functions.
[0005] In a first aspect, this application provides a virtual function invocation method, which includes: a computing device responding to a first process initiating a call request for a target virtual function through an object stored in shared memory, determining the target data type, wherein the target data type is the data type to which the object belongs during initialization; the computing device obtaining a first virtual function table pointer corresponding to the target data type according to a first correspondence relationship, wherein the aforementioned first correspondence relationship is the correspondence between the first virtual function table pointers determined according to the address space range corresponding to the first process and the data types corresponding to each first virtual function table pointer; and the computing device invoking the target virtual function through the virtual function table pointed to by the first virtual function table pointer.
[0006] It is understandable that, since the first correspondence is the correspondence between the first virtual function table pointer determined by the address space range corresponding to the first process and the data types corresponding to each first virtual function table pointer, after the computing device determines the target data type of the object, it can obtain the first virtual function table pointer corresponding to the first process and the target data type according to the first correspondence, thereby ensuring that the first process can call virtual functions smoothly.
[0007] In one possible implementation, the computing device determines the target data type by: obtaining a first identifier from the data structure of an object in shared memory; wherein the first identifier represents the target data type and is independent of the address space range corresponding to the first process.
[0008] It is understandable that after obtaining the first identifier representing the target data type, the computing device can determine the target data type. Furthermore, the first identifier is independent of the address space range corresponding to the first process. Therefore, the address space range of the first process can be allocated arbitrarily without the need for manual specification to load it to a fixed location, thereby improving the versatility of the virtual function call method provided in this application.
[0009] In one possible implementation, the computing device obtains a pointer to a first virtual function table corresponding to the target data type according to a first correspondence, including: the computing device obtains a pointer to a first virtual function table corresponding to a first identifier according to the first correspondence.
[0010] Understandably, since the first correspondence is the correspondence between the first virtual function table pointer determined by the address space range corresponding to the first process and the data types corresponding to each first virtual function table pointer, and the first identifier represents the target data type, the computing device can obtain the corresponding first virtual function table pointer through the first correspondence and the first identifier. Moreover, it ensures that the first virtual function table pointer corresponds to the first process in the dimension of address pointing and corresponds to the data type of the object corresponding to the call request at the time of initialization, thereby improving the accuracy of the computing device when calling virtual functions.
[0011] In one possible implementation, after the computing device obtains the first virtual function table pointer corresponding to the target data type according to the first correspondence, the method further includes: the computing device writing the second correspondence into the data structure of the object in shared memory, wherein the aforementioned second correspondence is the correspondence between the first process and the first virtual function table pointer.
[0012] It is understandable that after the computing device obtains the pointer to the first virtual function table corresponding to the target data type, it writes the correspondence between the first process and the pointer to the first virtual function table into the data structure of the object in shared memory, which helps to improve the efficiency of the computing device in processing the same call request again.
[0013] In one possible implementation, the computing device writes the second correspondence into the data structure of the object in shared memory, including: the computing device obtaining a second identifier, which represents the first process, and then the computing device writing the second identifier and a first virtual function table pointer into the data structure of the object.
[0014] Understandably, the computing device writes the second identifier representing the first process and the pointer to the first virtual function table into the object's data structure. In other words, it records the process identifier that initiated the virtual function call request in shared memory, which helps improve the efficiency of the computing device when it processes the same call request again.
[0015] In one possible implementation, after the computing device writes the second correspondence into the data structure of the object in shared memory, the method further includes: in response to the second process initiating a call request to the target virtual function through the object, the computing device determines that the second process and the first process are the same process according to the second correspondence; the computing device calls the target virtual function through the virtual function table pointed to by the pointer to the first virtual function table in the object's data structure.
[0016] Understandably, after writing the second correspondence, in response to the second process initiating a call request to the target virtual function through the object, the computing device can determine that the second process and the first process are the same process based on the second correspondence. If the identifiers of the two processes are consistent, the computing device can directly call the target virtual function through the virtual function table pointed to by the first virtual function table pointer in the object's data structure, without going through the first correspondence. Since in some complex scenarios, the first correspondence may contain a large number of different virtual function table pointers and the data types corresponding to each virtual function table pointer, and the data in shared memory is usually stored only once, this can improve the efficiency of the computing device in obtaining the virtual function table pointer, thereby improving the overall efficiency of virtual function calls.
[0017] In one possible implementation, after the computing device writes the second correspondence into the data structure of the object in shared memory, the method further includes: in response to the second process initiating a call request to the target virtual function through the object, the computing device determines, based on the second correspondence, that the second process and the first process are not the same process; then, the computing device obtains a second virtual function table pointer corresponding to the target data type based on a third correspondence, wherein the third correspondence is the correspondence between the first virtual function table pointers determined based on the address space range corresponding to the second process and the data types corresponding to each first virtual function table pointer; and then the computing device calls the target virtual function through the virtual function table pointed to by the second virtual function table pointer.
[0018] Understandably, when the computing device determines, based on the second correspondence, that the second process and the first process are not the same process, for example, when a process switch occurs, the computing device can also obtain the pointer to the second virtual function table corresponding to the target data type through the third correspondence, ensuring that the second process can successfully call the virtual function and improving the versatility of the virtual function calling method provided in this application.
[0019] Secondly, this application provides a virtual function calling device for executing any of the virtual function calling methods provided in the first aspect above.
[0020] In one possible implementation, this application can divide the virtual function calling device into functional modules according to the method provided in the first aspect above. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one processing module. For example, this application can divide the virtual function calling device into a determination module, an acquisition module, and a calling module according to function. The descriptions of the possible technical solutions and beneficial effects of the above-described functional modules can be found in the technical solutions provided in the first aspect above or its corresponding possible implementations, and will not be repeated here.
[0021] Thirdly, embodiments of this application provide a computing device that includes a processor and a memory, the processor being coupled to the memory; the memory is used to store computer instructions that are loaded and executed by the processor to enable the computing device to implement the virtual function call method as described above.
[0022] Fourthly, embodiments of this application provide a computer-readable storage medium storing at least one computer program instruction, which is loaded and executed by a processor to implement the virtual function call method as described above.
[0023] Fifthly, embodiments of this application provide a computer program product including computer instructions stored in a computer-readable storage medium. A processor of a computing device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computing device to perform the virtual function call methods provided in the various optional implementations of the first aspect described above.
[0024] For a detailed description of the second to fifth aspects and their various implementations in this application, please refer to the detailed description in the first aspect and its various implementations; and for a detailed analysis of the beneficial effects of the second to fifth aspects and their various implementations in the first aspect and its various implementations, please refer to the beneficial effect analysis in the first aspect and its various implementations, which will not be repeated here.
[0025] These or other aspects of this application will become more readily apparent in the following description. Attached Figure Description
[0026] Figure 1 A schematic diagram illustrating the virtual function call process in a non-shared memory scenario, provided as an embodiment of this application;
[0027] Figure 2 This is a schematic diagram illustrating the inability to call virtual functions across processes in a shared memory scenario, as provided in an embodiment of this application.
[0028] Figure 3 A schematic diagram illustrating data splitting related to an embodiment of this application;
[0029] Figure 4 A schematic diagram illustrating address alignment in another related technology provided for an embodiment of this application;
[0030] Figure 5 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application;
[0031] Figure 6 A flowchart illustrating a virtual function call method provided in this application embodiment;
[0032] Figure 7 for Figure 6 The illustrated embodiment is a schematic diagram of obtaining a first identifier;
[0033] Figure 8 for Figure 6 The illustrated embodiment is a schematic diagram of a first correspondence relationship;
[0034] Figure 9 for Figure 6 The illustrated embodiment is a schematic diagram of obtaining a virtual function table pointer;
[0035] Figure 10 for Figure 6 The illustrated embodiment is a schematic diagram of a virtual function call.
[0036] Figure 11 for Figure 6 The illustrated embodiment is a schematic diagram of a data structure.
[0037] Figure 12 A flowchart illustrating another virtual function call method provided in this application embodiment;
[0038] Figure 13 for Figure 12 The illustrated embodiment is a schematic diagram of a method for determining whether processes are identical;
[0039] Figure 14 for Figure 12 The illustrated embodiment is a schematic diagram of a virtual function call.
[0040] Figure 15 This is a schematic diagram of a virtual function calling device provided in an embodiment of this application. Detailed Implementation
[0041] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.
[0042] In this article, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.
[0043] Furthermore, in the description of the embodiments of this application, unless otherwise stated, "multiple" refers to two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.
[0044] Furthermore, to facilitate a clear description of the technical solutions in the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" are not necessarily different. Meanwhile, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is being used as an example, illustration, or description. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present related concepts in a concrete manner for ease of understanding.
[0045] First, the application scenarios of the embodiments of this application will be introduced by way of example.
[0046] When writing code, we often encounter many reusable functions, variables, objects, etc. If we have to rewrite the code every time, it will seriously reduce work efficiency and code readability, and we will not be able to reuse our code in other projects. Therefore, we can choose to encapsulate the function code into a library file, thereby improving work efficiency and making it easier for other projects to call it.
[0047] A shared library is a library that provides functions, variables, and other resources that can be used by multiple processes simultaneously, such as a dynamic link library (DLL). During program compilation, shared libraries do not need to be compiled into each executable file separately; instead, they are loaded into memory only when the process needs them (also known as dynamic linking).
[0048] For the purpose of resource sharing and efficiency improvement, some resources in the shared library can be loaded into shared memory. Since shared memory is a high-performance inter-process communication method, it can significantly improve the communication efficiency between different processes. See Table 1 below for details. Table 1 shows the performance and characteristics of three different inter-process communication methods. Since shared memory does not need to copy the data to be transferred when transferring data between processes, it is more efficient and has better performance.
[0049] socket adhesive binder Shared memory performance Two copies Copy once No need to copy Features Low transmission efficiency and high overhead High ease of use Control complexity
[0050] Table 1
[0051] In the field of object-oriented programming, virtual functions are a very important language feature. They can help programs achieve dynamic polymorphism, thereby hiding implementation details, making code modular, improving code reusability, and also helping programs achieve interface reuse. This allows the functionality of derived classes to be called by pointers to base classes, improving code extensibility and maintainability. The aforementioned shared libraries often involve calling virtual functions.
[0052] In non-shared memory scenarios, the relevant virtual function call flow can be found in [link to relevant documentation]. Figure 1 , Figure 1 A flowchart illustrating a virtual function call in a non-shared memory scenario, provided for embodiments of this application, typically includes:
[0053] S110, the processor obtains the call request for the target virtual function.
[0054] For example, this step occurs when the processor executes program code such as "call obj.A.funcA", which is typically a request to call a target virtual function initiated by an object. Figure 1 In this context, process A initiates a call request to the target virtual function through object A.
[0055] S120, the processor obtains the virtual function table pointer.
[0056] In the relevant call flow, the processor will then directly retrieve the corresponding virtual pointer (VPTR) from the data structure of object A stored in the address space of process A. Figure 1 The data structure of object A shown includes a virtual function table pointer, member variable 1, member function 1, etc.
[0057] Figure 1 The VPTR in the table is determined based on the address space range of process A. Therefore, the VPTR can accurately point to the virtual function table in process A. The virtual function table usually includes the address of the target virtual function to be called. The virtual function table is usually distinguished according to the data type. That is to say, different data types correspond to different virtual function tables, and therefore the VPTRs are also different; while the virtual function tables corresponding to the same data type are the same, and therefore the VPTRs are also the same.
[0058] S130, the processor obtains the address of the target virtual function.
[0059] Based on the pointer to VPTR obtained in step S120, the processor finds the address of the target virtual function from the corresponding virtual function table and finally implements the call to the target virtual function.
[0060] However, the aforementioned virtual function call flow cannot be directly applied to shared memory scenarios. The following section, in conjunction with the appendix... Figure 2 To provide an explanation, in order to Figure 1 Taking object A as an example, which is placed into shared memory, Figure 2 This is a schematic diagram illustrating the inability to call virtual functions across processes in a shared memory scenario provided by an embodiment of this application. Since the address space ranges allocated to processes A and B are often different, the VPTR determined based on their respective address space ranges are also often different.
[0061] During execution, processes B and A will successively write their respective VPTRs to the data structure of object A in shared memory. Since data in shared memory is typically stored only once, the value of the VPTR written later will overwrite the value written earlier. Figure 2 In the above, process A is the process that wrote to the VPTR later, therefore Figure 2 The VPTR in the data structure of object A in the shared memory shown can only accurately point to the virtual function table within the address space of process A, thus allowing process A to call virtual functions normally. However, this VPTR can only point to... Figure 2 The data shown is located within the address space of process B, but cannot correctly point to the virtual function table in process B. Figure 2 (As shown by the dashed line in the middle), in some cases, the location pointed to by the VPTR may even be outside the address space of process B, becoming an inaccessible illegal address. This results in process A and process B being unable to call virtual functions normally at the same time in shared memory scenarios.
[0062] Furthermore, if a larger number of processes participate in the sharing, it is very likely that only one process will be able to call the virtual function normally, while the rest of the processes will not be able to call the virtual function normally.
[0063] To address the aforementioned issues, one related technique proposes splitting objects originally stored in shared memory, as detailed below. Figure 3 , Figure 3 This application provides a schematic diagram of data splitting related to an embodiment of the present invention, wherein object A is split according to data (specifically including...) Figure 3 The member variables 1 and 2 shown are related to the methods (specifically including...). Figure 3 The two different types of member function 1 and member function 2 shown are split into sub-object A and sub-object B. Since the data of the method type in sub-object B may involve virtual functions, this part of the data is not placed in shared memory. However, the data of the data type in sub-object A does not involve virtual functions, so this part of the data can be placed in shared memory.
[0064] In other words, this method still places the parts involving virtual functions in non-shared memory, although it can guarantee that the process can pass through. Figure 1 The process shown calls virtual functions normally, but this results in data that may contain virtual functions (such as...). Figure 3 Sub-objects B) in the shared memory cannot enjoy its superior performance. Furthermore, developers were originally able to tailor their code to business characteristics and actual needs. Figure 3 The object A shown can be defined freely and flexibly. However, in this solution, developers need to forcibly split the data in the data structure of the same object according to type, which seriously damages the integrity of the object. Moreover, this data splitting approach is contrary to the object-oriented programming concept. It loses the integrity of business logic in the object-oriented programming process, which greatly reduces the readability, maintainability and extensibility of the code.
[0065] In another related technology, see [link to relevant documentation] for details. Figure 4 , Figure 4 This is a schematic diagram of address alignment related to another relevant technology provided in an embodiment of this application. In this solution, it is first necessary to ensure... Figure 4 The address spaces of processes A and B overlap. Then, the shared library involving virtual function calls is loaded into a pre-fixed address within this overlapping space, thereby achieving the desired result. Figure 4 The virtual function table shown is address aligned, thus enabling Figure 4 The virtual function table pointer of object A in the shared memory shown can point to the virtual function tables of both processes, ensuring that the processes can access each other's virtual function tables. Figure 1 The process shown calls the virtual function normally.
[0066] However, this method of loading shared libraries into pre-fixed locations has a very limited applicability. It can only be implemented in some simple systems (with a small number of processes running), and developers need to customize the loading location of each shared library. In complex systems, once the number of shared libraries that need to be pre-fixed reaches a certain level, it cannot be guaranteed that there is enough address space available for pre-fixing.
[0067] In view of this, embodiments of this application provide a virtual function calling method, which improves the virtual function calling process in a shared memory scenario. After the computing device receives a virtual function call request, it first determines the data type of the object corresponding to the call request, and then obtains the virtual function table pointer determined according to the address space range of the process based on the data type. This enables the use of the superior performance of shared memory while preserving the original object-oriented data structure, and normal calling of virtual functions to take advantage of the various characteristics of virtual functions.
[0068] In some feasible embodiments, the virtual function invocation method includes: in response to a first process initiating a call request to a target virtual function through an object stored in shared memory, determining the target data type, wherein the target data type is the data type to which the object belongs during initialization; obtaining a first virtual function table pointer corresponding to the target data type according to a first correspondence; the first correspondence is the correspondence between the first virtual function table pointers determined according to the address space range corresponding to the first process and the data types corresponding to each first virtual function table pointer; and invoking the target virtual function through the virtual function table pointed to by the first virtual function table pointer. Because the computing device, through the first correspondence and the target data type, can obtain a virtual function table pointer corresponding to the process initiating the call request and corresponding to the data type to which the object belongs during initialization, while ensuring that the object can be completely stored in shared memory, it guarantees that the process can successfully invoke the virtual function, thereby achieving the ability to use the virtual function feature without restriction while using high-performance shared memory.
[0069] Secondly, the system architecture of the embodiments of this application will be described by way of example.
[0070] like Figure 5 As shown, Figure 5 This is a schematic diagram of a computing device provided in an embodiment of this application. The computing device 1000 includes at least: a memory 1010, a processor 1020, and a bus 1030.
[0071] The memory 1010 can be used to store the logic code corresponding to the virtual function call method provided in the embodiments of this application, or in other words, the memory 1010 can store the logic code corresponding to the execution of a certain step by the computing device 1000 described in the following embodiments.
[0072] The processor 1020 can be used to determine the target data type of an object, obtain the pointer to the first virtual function table corresponding to the target data type, and call the target virtual function through the virtual function table pointed to by the virtual function table pointer, etc.
[0073] Bus 1030 can be used to transmit interactive data between processor 1020 and memory 1010.
[0074] Optionally, the computing device 1000 can be a terminal device or a network device. The terminal device can include computers, mobile terminals, tablets, laptops, desktop computers, all-in-one computers, augmented reality (AR) devices, virtual reality (VR) devices, mixed reality (MR) devices, extended reality (ER) devices, personal digital assistants (PDAs), ultra-mobile personal computers (UMPCs), etc. The terminal device can also include edge computing devices (e.g., a box carrying a processing chip). The network device can include servers, etc.
[0075] Optionally, the memory 1010 may include random access memory (RAM), read-only memory (ROM), etc., wherein the RAM in the memory 1010 can run the necessary operating system, as well as modules such as a determination module, an acquisition module, and a calling module for executing the virtual function call method provided in this application.
[0076] Optionally, the processor 1020 can be a central processing unit (CPU) or other general-purpose processor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), digital signal processor (DSP) or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, etc. The general-purpose processor can be a microprocessor or any conventional processor.
[0077] Optionally, the bus 1030 can be a peripheral component interconnect (PCI) bus or a peripheral component interconnect express (PCIe) bus, etc. For ease of illustration, Figure 5The bus 1030 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 1030 may include a path for transmitting information between various components of the computing device 1000 (e.g., memory 1010, processor 1020).
[0078] It should be noted that the application scenarios and system architectures described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.
[0079] For ease of understanding, the virtual function calling method provided in this application is described below with reference to the accompanying drawings. This virtual function calling method is applicable to... Figure 5 The computing device shown.
[0080] It should be noted that the execution of a certain step (such as S210 to S230 below) by the computing device described in the following embodiments can be understood as the processor 1020 executing the step.
[0081] Figure 6 The flowchart of a virtual function calling method provided in an embodiment of this application is shown. The virtual function calling method specifically includes the following steps:
[0082] S210, the computing device responds to the first process's request to call the target virtual function through an object stored in shared memory, and determines the target data type.
[0083] In this step, when the computing device executes the code of each program, specifically when it executes the code that calls a virtual function, it obtains a call request for the target virtual function. Moreover, this request is initiated through an object stored in shared memory. The computing device can then access the metadata related to the data type of the object stored in the data structure of the object in shared memory. This metadata related to the data type is globally unique and independent of the address space range of a specific process. In this embodiment, this metadata related to the data type can also be called a global identifier (GID).
[0084] In other words, whether it's process A, process B, or any other process running on the computing device that initiates a call request to the target virtual function through a specific object (e.g., object A) stored in shared memory, the data type-related metadata stored in the object's data structure is consistent. Furthermore, this metadata records the data type the object belonged to during object initialization; that is, the target data type determined by the computing device in step S210 is the data type the object belonged to during object initialization.
[0085] In one possible implementation, the computing device can obtain a first identifier from the data structure of an object in shared memory; wherein the first identifier represents the target data type and is independent of the address space range corresponding to the first process, so that the computing device can determine the data type to which the object belongs when it is initialized through the first identifier.
[0086] For example, see Figure 7 , Figure 7 for Figure 6 The illustrated embodiment relates to a schematic diagram of obtaining a first identifier. At least two processes, process A and process B, are running on the computing device. Either process A or process B can be the first process mentioned in step S210. Process A and process B can share an object A stored in shared memory. Object A stores at least a data type identifier (first identifier) and some other members (not shown in the figure). The computing device executes the code "Call obj.A.funcA" corresponding to process A and process B respectively, representing a call to a virtual function (funcA) through object A (obj.A) in shared memory. Figure 7 The function declarations not shown in the code have declared them as virtual functions, and will not be explained in detail here.
[0087] Figure 7 The data type identifier shown can specifically be a hash value calculated based on the data of the data type to which object A belongs during initialization. The hash value can be calculated using various algorithms, such as Message Digest Algorithm 5 (MD5) or Secure Hash Algorithm (SHA), and this application does not impose any restrictions on this. Different data types can each correspond to a globally unique hash value, and this value is independent of the address space range allocated to a specific process.
[0088] S220, the computing device obtains the pointer to the first virtual function table corresponding to the target data type according to the first correspondence.
[0089] The first correspondence is the correspondence between the virtual function table pointers determined based on the address space range of the first process and the data types corresponding to each virtual function table pointer. In other words, in this embodiment, each process that needs to call virtual functions through objects in shared memory can determine its own virtual function table pointers based on the correspondence between the virtual function table pointers determined by its corresponding address space range and the data types corresponding to each virtual function table pointer. For details, please refer to... Figure 8 , Figure 8 for Figure 6 The illustrated embodiment is a schematic diagram of a first correspondence relationship, wherein, Figure 8 The first correspondence of process A shown includes: identifier A corresponds to virtual function table pointer A, identifier B corresponds to virtual function table pointer B, and identifier C corresponds to virtual function table pointer C. Virtual function table pointers A, B, and C are all determined based on the address space range corresponding to process A. The first correspondence of process B includes: identifier A corresponds to virtual function table pointer D, identifier B corresponds to virtual function table pointer E, and identifier C corresponds to virtual function table pointer F. Virtual function table pointers D, E, and F are all determined based on the address space range corresponding to process B.
[0090] In one possible implementation, the computing device can obtain the pointer to the first virtual function table corresponding to the first identifier based on the first correspondence.
[0091] For example, through the aforementioned step S210, the computing device can obtain the first identifier. Then, when executing step S220, the computing device can obtain the first virtual function table pointer corresponding to the first identifier from the address space range corresponding to the first process. See [link to details]. Figure 9 , Figure 9 for Figure 6 The illustrated embodiment is a schematic diagram of obtaining a virtual function table pointer, wherein, Figure 9 The first correspondence shown is with Figure 8 The above is consistent with the previous description and will not be elaborated upon here. In a specific implementation, the aforementioned correspondence can be stored in the form of a table. Then, after the computing device obtains the identifier B from the object in shared memory, it can retrieve the virtual function table pointer corresponding to identifier B by looking up the table. Since identifier B can represent a specific target data type, it can be said that the computing device obtains the virtual function table pointer corresponding to the target data type. The specific values in the aforementioned first correspondence table can be determined during the initialization process based on the address space range of each process when the shared library is loaded.
[0092] Specifically, the computing device responds to Figure 9The process A shown initiates a virtual function call request through object A in shared memory. The computing device obtains the identifier B from the data structure of object A, and then looks up the VPTR corresponding to identifier B in the GID and VPTR mapping table stored in the address space range corresponding to process A. Figure 9 The VPTR is shown in Figure B. Similarly, if the call request is initiated by process B, the computing device will look up the corresponding GID and VPTR in the address space range of process B. Since the VPTR in the GID and VPTR correspondence table of each process is determined according to the address space range of each process, the virtual function table pointer obtained by the computing device in step S220 can ensure that the process that initiated the call request can successfully call the virtual function.
[0093] S230, the computing device calls the target virtual function through the virtual function table pointed to by the first virtual function table pointer.
[0094] Because the computing device can ensure, through the aforementioned steps, that the virtual function table pointer obtained by the computing device corresponds to the process that initiated the call request in terms of address and to the data type of the object corresponding to the call request during initialization, the computing device can guarantee that the process can successfully call the virtual function.
[0095] For example, see details. Figure 10 , Figure 10 for Figure 6 The illustrated embodiment is a schematic diagram of a virtual function call. Figure 10 The demonstration shows that, taking process A as an example, after the computing device obtains VPTR B, it calls the corresponding virtual function. The address range corresponding to process A includes virtual function table A for data type A and virtual function table B for data type B. That is, different virtual function tables correspond to different data types. In the aforementioned process, process A initiates a call request to virtual function A through object A in shared memory. The computing device then obtains identifier B from the data structure of object A. Since the target data type corresponding to identifier B is data type B, VPTR B is obtained from the GID and VPTR mapping table of process A. Then, in step S230, virtual function A can be called through virtual function table B pointed to by VPTR B, thus realizing virtual function calls in a shared memory scenario.
[0096] Through the above steps S210-S230, when the object can be completely stored in shared memory, the computing device obtains the virtual function table pointer corresponding to the process that initiated the call request and the data type to which the object belongs during initialization through the first correspondence, ensuring that the process can call the virtual function smoothly. This achieves the ability to use the virtual function feature without restriction while using high-performance shared memory.
[0097] Optionally, in order to further improve the efficiency of the computing device in processing virtual function call requests, after the computing device obtains the first virtual function table pointer corresponding to the target data type, it can also write the second correspondence into the data structure of the object in shared memory, wherein the second correspondence is the correspondence between the first process and the first virtual function table pointer.
[0098] Specifically, see Figure 11 , Figure 11 for Figure 6 The illustrated embodiment is a schematic diagram of a data structure, which, compared with the aforementioned figures, Figure 11 The data structure of object A in the shared memory shown has two additional bit fields: a virtual function table pointer and a process identifier. This allows the computing device to obtain the accurate first virtual function table pointer through the first correspondence and then write the second correspondence into the corresponding bit fields to accelerate the subsequent virtual function call process.
[0099] In one possible implementation, the computing device may first obtain a second identifier, and then write the second identifier and a pointer to a first virtual function table into the object's data structure, wherein the second identifier represents the first process.
[0100] Thus, based on the aforementioned virtual function call method, we can obtain the following: Figure 12 The flowchart shown is as follows. Figure 12 A flowchart of another virtual function call method provided in the embodiments of this application specifically includes:
[0101] S310, the computing device responds to the second process's request to call the target virtual function through the object, and determines whether the second process and the first process are the same process based on the second correspondence.
[0102] In this embodiment, since processes using shared memory may initiate virtual function call requests through objects stored in shared memory, if the virtual function table pointer stored in shared memory is used directly to accelerate the virtual function call process, the computing device needs to first confirm whether the virtual function table pointer can be applied to the process initiating the call request. Since the virtual function table pointer is determined and written by the computing device after responding to the virtual function call request initiated by the first process, it is necessary to confirm whether the second process initiating the call request is the same process as the first process. Only if the second process and the first process are the same process can the processing of its virtual function call request be accelerated.
[0103] In step S310, the computing device can obtain the identifier of the current second process through the operating system's call interface, and match it with the second identifier in the second correspondence relationship. Based on the matching result, it can determine whether the second process and the first process are the same process.
[0104] For example, see Figure 13 , Figure 13 for Figure 12 The illustrated embodiment relates to a schematic diagram of determining whether processes are the same. The computing device obtains the current process identifier (TPID) of the second process through the operating system interface and then matches it with a second identifier in the data structure of object A in shared memory. If the identifiers match, the computing device can determine that the second process and the first process are the same process, and then the computing device continues to execute step S320. Conversely, if the identifiers do not match, the computing device can determine that the second process and the first process are not the same process, and then the computing device continues to execute step S330. Figure 13 The data structure of object A shown also includes other data such as data type identifiers and virtual function table pointers.
[0105] S320, the computing device calls the target virtual function through the virtual function table pointed to by the pointer to the first virtual function table in the object's data structure.
[0106] In this step, the computing device has determined that the second process and the first process are the same process based on the second correspondence. That is, the current process (the second process) recently called the corresponding virtual function through this object in shared memory, and no process switching occurred. The pointer to the first virtual function table in the data structure of this object in shared memory was stored by the computing device in response to the previous virtual function call request of the process, so it can be used directly. Thus, the computing device realizes that the process successfully calls the virtual function.
[0107] For example, see Figure 14 , Figure 14 for Figure 12The illustrated embodiment is a schematic diagram of a virtual function call. Figure 14 In this process, the computing device has determined that process A and the first process are the same process by comparing the process identifier of process A with the process identifier A in the data structure of object A in shared memory. In other words, the VPTR B in the data structure of object A in shared memory corresponds to process A and can accurately point to the virtual function table B of process A (which includes virtual functions A, B, and C, etc.). Therefore, the computing device can directly call the target virtual function through the virtual function table B pointed to by the VPTR B in the data structure of object A in shared memory, which significantly improves the efficiency of virtual function calls.
[0108] S330, the computing device obtains the pointer to the second virtual function table corresponding to the target data type according to the third correspondence.
[0109] The third correspondence is the correspondence between the first virtual function table pointer determined according to the address space range corresponding to the second process and the data types corresponding to each first virtual function table pointer. In the embodiments of this application, the third correspondence is similar to the aforementioned first correspondence, the main difference being that the virtual function table pointer is determined according to the address space range corresponding to different processes.
[0110] In this step, the computing device has determined that the second process and the first process are not the same process based on the second correspondence. That is to say, the current process (the second process) may be calling the corresponding virtual function for the first time through this object in shared memory, or it may have been called before, but an event such as a process switch occurred, causing the process identifier included in the aforementioned second correspondence to be the identifier of another process.
[0111] Furthermore, the pointer to the first virtual function table in the data structure of the object in the shared memory is difficult to accurately point to the virtual function table in the second process. Therefore, the computing device needs to obtain the pointer to the second virtual function table corresponding to the target data type according to the third correspondence. This process can refer to the aforementioned steps S210-S220, which will not be elaborated here.
[0112] Furthermore, in one possible implementation, the computing device can write the correspondence between the second virtual function table pointer and the second process into the data structure of the object in shared memory, which can improve the efficiency of the computing device in handling virtual function call requests initiated by the second process.
[0113] S340, the computing device calls the target virtual function through the virtual function table pointed to by the second virtual function table pointer.
[0114] This step is similar to step S230 mentioned above, and will not be described in detail here.
[0115] Through steps S310-S340, the computing device can directly call the target virtual function through the virtual function table pointed to by the pointer of the first virtual function table in the data structure of the object in shared memory, provided that no process switching has occurred (i.e., the second process and the first process are the same process). Therefore, in some scenarios with low process switching frequency, the efficiency of the computing device in handling virtual function call requests can be significantly improved.
[0116] It should be noted that the logic code corresponding to the virtual function call method provided in this application embodiment does not need to be written by the user. Instead, it can be generated and inserted by the compiler based on the code written by the user when compiling the program code. In other words, the user only needs to develop the program according to the normal writing rules. In other words, the virtual function call method provided in this application embodiment will not impose any restrictions or burdens on the developers, and can also take into account the high performance of shared memory and the multiple characteristics of virtual functions.
[0117] The foregoing mainly describes the solutions of the embodiments of this application from a methodological perspective. It is understood that, in order to implement the above-mentioned functions, the virtual function call device includes at least one of the hardware structures and software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this application.
[0118] This application embodiment can divide the virtual function call device into functional units according to the above method example. For example, each function can be divided into a separate functional unit, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.
[0119] For example, Figure 15 This is a schematic diagram of a virtual function calling device provided in an embodiment of this application. Figure 15 The virtual function call device 800 shown can be applied in a computing device, or the virtual function call device 800 can be a computing device. The virtual function call device 800 includes:
[0120] The determination module 810 is used to determine the target data type in response to a call request to the target virtual function initiated by the first process through an object stored in shared memory. The target data type is the data type to which the object belongs during initialization.
[0121] The acquisition module 820 is used to acquire the first virtual function table pointer corresponding to the target data type according to the first correspondence relationship, wherein the aforementioned first correspondence relationship is the correspondence between the first virtual function table pointer determined according to the address space range corresponding to the first process and the data type corresponding to each first virtual function table pointer.
[0122] Module 830 is used to call the target virtual function through the virtual function table pointed to by the first virtual function table pointer.
[0123] For example, combining Figure 6 The determination module 810 can be used to perform, for example... Figure 6 As shown in S210, the acquisition module 820 can be used to perform, for example... Figure 6 As shown in S220, module 830 can be used to execute, for example... Figure 6 S230 is shown.
[0124] In one possible implementation, the determining module 810 is further configured to obtain a first identifier from the data structure of the object in the shared memory; wherein the first identifier represents the target data type, and the first identifier is independent of the address space range corresponding to the first process.
[0125] In one possible implementation, the acquisition module 820 is further configured to acquire a first virtual function table pointer corresponding to the first identifier based on the first correspondence.
[0126] In one possible implementation, the apparatus further includes a writing module for writing a second correspondence into the data structure of an object in the shared memory, the second correspondence being the correspondence between the first process and the first virtual function table pointer.
[0127] In one possible implementation, the writing module is further configured to: obtain a second identifier, the second identifier representing the first process; and write the second identifier and the first virtual function table pointer into the data structure of the object.
[0128] In one possible implementation, the apparatus further includes a second invocation module, which is configured to, in response to a second process initiating a call request to the target virtual function through the object, determine that the second process and the first process are the same process according to the second correspondence; and invoke the target virtual function through the virtual function table pointed to by the first virtual function table pointer in the data structure of the object.
[0129] In one possible implementation, the device further includes a third invocation module, which is configured to, in response to a second process initiating a call request to the target virtual function through the object, determine, based on the second correspondence, that the second process and the first process are not the same process; obtain, based on the third correspondence, a second virtual function table pointer corresponding to the target data type; the third correspondence is the correspondence between the first virtual function table pointers determined according to the address space range corresponding to the second process and the data types corresponding to each of the first virtual function table pointers; and invoke the target virtual function through the virtual function table pointed to by the second virtual function table pointer.
[0130] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to execute a virtual function call method.
[0131] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute a virtual function call method, or instruct the computing device to execute a virtual function call method.
[0132] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions 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 virtual function call method, characterized in that, The method includes: In response to the first process initiating a call request to the target virtual function through an object stored in shared memory, the target data type is determined, wherein the target data type is the data type to which the object was initialized; According to the first correspondence, obtain the first virtual function table pointer corresponding to the target data type; the first correspondence is the correspondence between the first virtual function table pointer determined according to the address space range corresponding to the first process and the data type corresponding to each first virtual function table pointer; The target virtual function is called through the virtual function table pointed to by the first virtual function table pointer.
2. The method according to claim 1, characterized in that, The determination of the target data type includes: Obtain a first identifier from the data structure of the object in the shared memory; wherein the first identifier represents the target data type and is independent of the address space range corresponding to the first process.
3. The method according to claim 2, characterized in that, The step of obtaining the pointer to the first virtual function table corresponding to the target data type according to the first correspondence includes: Based on the first correspondence, obtain the pointer to the first virtual function table corresponding to the first identifier.
4. The method according to any one of claims 1-3, characterized in that, After obtaining the pointer to the first virtual function table corresponding to the target data type according to the first correspondence, the method further includes: The second correspondence is written into the data structure of the object in the shared memory. The second correspondence is the correspondence between the first process and the first virtual function table pointer.
5. The method according to claim 4, characterized in that, The step of writing the second correspondence into the data structure of the object in the shared memory includes: Obtain a second identifier, which represents the first process; Write the second identifier and the first virtual function table pointer into the data structure of the object.
6. The method according to claim 4 or 5, characterized in that, After writing the second correspondence into the data structure of the object in the shared memory, the method further includes: In response to the second process initiating a call request to the target virtual function through the object, the second process and the first process are determined to be the same process according to the second correspondence. The target virtual function is called through the virtual function table pointed to by the pointer to the first virtual function table in the data structure of the object.
7. The method according to claim 4 or 5, characterized in that, After writing the second correspondence into the data structure of the object in the shared memory, the method further includes: In response to the second process initiating a call request to the target virtual function through the object, it is determined, based on the second correspondence, that the second process and the first process are not the same process; According to the third correspondence, obtain the second virtual function table pointer corresponding to the target data type; the third correspondence is the correspondence between the first virtual function table pointer determined according to the address space range corresponding to the second process and the data types corresponding to each first virtual function table pointer; The target virtual function is called through the virtual function table pointed to by the second virtual function table pointer.
8. A virtual function call device, characterized in that, The device includes: The determination module is used to determine the target data type in response to a call request to the target virtual function initiated by the first process through an object stored in shared memory. The target data type is the data type to which the object belongs during initialization. The acquisition module is used to acquire a first virtual function table pointer corresponding to the target data type according to a first correspondence relationship; the first correspondence relationship is the correspondence between the first virtual function table pointers determined according to the address space range corresponding to the first process and the data types corresponding to each first virtual function table pointer; The calling module is used to call the target virtual function through the virtual function table pointed to by the first virtual function table pointer.
9. The apparatus according to claim 8, characterized in that, The determining module is further used for, Obtain a first identifier from the data structure of the object in the shared memory; wherein the first identifier represents the target data type and is independent of the address space range corresponding to the first process.
10. The apparatus according to claim 9, characterized in that, The acquisition module is also used for, Based on the first correspondence, obtain the pointer to the first virtual function table corresponding to the first identifier.
11. The apparatus according to any one of claims 8-10, characterized in that, The device further includes a writing module, the writing module being used for, The second correspondence is written into the data structure of the object in the shared memory. The second correspondence is the correspondence between the first process and the first virtual function table pointer.
12. The apparatus according to claim 11, characterized in that, The writing module is also used for, Obtain a second identifier, which represents the first process; Write the second identifier and the first virtual function table pointer into the data structure of the object.
13. The apparatus according to claim 11 or 12, characterized in that, The device further includes a second invocation module, the second invocation module being used for, In response to the second process initiating a call request to the target virtual function through the object, the second process and the first process are determined to be the same process according to the second correspondence. The target virtual function is called through the virtual function table pointed to by the pointer to the first virtual function table in the data structure of the object.
14. The apparatus according to claim 11 or 12, characterized in that, The device further includes a third invocation module, the third invocation module being used for, In response to the second process initiating a call request to the target virtual function through the object, it is determined, based on the second correspondence, that the second process and the first process are not the same process; According to the third correspondence, obtain the second virtual function table pointer corresponding to the target data type; the third correspondence is the correspondence between the first virtual function table pointer determined according to the address space range corresponding to the second process and the data types corresponding to each first virtual function table pointer; The target virtual function is called through the virtual function table pointed to by the second virtual function table pointer.
15. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer instructions; when the computer instructions are executed in a computing device, the computing device performs the virtual function call method according to any one of claims 1 to 7.
16. A computing device, characterized in that, The computing device includes a processor and a memory; the processor is coupled to the memory; the memory is used to store computer instructions, which are loaded and executed by the processor to enable the computing device to implement the virtual function call method as described in any one of claims 1 to 7.
17. A computer program product, characterized in that, When the computer program product is run on a computing device, the computing device executes the virtual function call method according to any one of claims 1 to 7.