JPH10320203A - Shared memory system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To enable the use of virtual function without damaging the shared function of real memory while unnecessitating reference structure and address calculation with a pointer by fixing the address of virtual function table. SOLUTION: In a shared memory system in which plural application processes share the object of class having the virtual function of object oriented system, the addresses of processes 1 and 2 in the virtual function table are made equal in all the programs sharing the object. Therefore, the class for preparing the shared object while having the virtual function is prepared as a shared library fixing its load address. Thus, it is not necessary to use any special data structure for preparing a reference relation, and pointer calculation for access is unnecessitated. Further, a page on the real memory can be shared between processes and efficiency in the utilization of real memory is improved.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to a shared memory system for sharing data having a complicated reference relationship such as an object of an object-oriented system, and more particularly to a shared memory system for sharing an object of a class having a virtual function. Related to a shared memory system.

[0002]

2. Description of the Related Art In an object-oriented system, it is required that an object structure having a complicated reference relationship can be simultaneously referenced and updated by a plurality of processes working in cooperation.

[0003] Currently, such a shared object is a commercially available object-oriented database management system (0bj).
ect Oriented Data Base Ma
This is realized by using N.Nagement System (OODBMS).

[0004] Object reference relation is simply C +
+ It can be realized by using a language pointer. However, in a commercially available OODBMS, as shown in FIG. 4, a special reference structure (reference) is created to make the reference relationship independent of the address space of the application process.

Although this method has the advantage that a large object structure exceeding the address space of the CPU can be created, the overhead is large since a pointer is internally calculated every time a reference is followed. Also,
Since OODBM-specific references are used instead of familiar pointers, there is also a problem that code is difficult to write.

In order to compensate for the above drawbacks, the reference structure is hidden in a language function so that it can be handled like a pointer.
In some cases, the pointer calculation is performed collectively for each page (virtual storage replacement unit) using the virtual storage mechanism (for example, 0objectStore (T
M)).

In this case, as shown in FIG. 5, since the pointer calculation is performed only at the time of loading the page (reading into the real memory), the efficiency is higher than the calculation for each access.

In the current system, pointer calculation is required for each access to a reference or each time a page is loaded, and the overhead for utilizing a reference relationship is large.
This overhead cannot be neglected in systems that frequently follow unrelated or real-time systems that require performance.

In the method of calculating the pointer for each page, the contents of the page existing in the real memory have different pointer values for each process. Therefore, the page entity in the real memory is shared between the processes. And the efficiency of using real memory is poor.

[0010] From these circumstances, when referring to data in the shared memory from a plurality of application processes, the address to which the shared memory is mapped is fixed.
There is a shared object system in which each application process refers to data using a pointer value.

In this system, as shown in FIG. 6, a process 1 and a process 2 are executed by a shared memory 3 indicated by a disk.
Can be referenced by a fixed address to share object data. In this way, the object appears to all processes to the same address, and the reference relationship can be constructed with a simple pointer. As a result, (1) there is no need to use a special data structure (reference) to create a reference relationship.

(2) It is not necessary to perform pointer calculation for access.

(3) The page on the real memory can be shared between processes, and the utilization efficiency of the real memory is improved.

[0014]

In the conventional shared memory system for performing a reference using a fixed address, there is an inconvenience when sharing an object of a class having a virtual function due to the following circumstances.

The virtual function of C ++ redefines (overrides) a method (virtual function) of the base class with a derived class.
In this case, when a method is called from a pointer of a base class that refers to an object of a derived class, a function redefined in the derived class is called.

To achieve this, the compiler converts (from a programmer) an object of a class with virtual functions.
Prepare hidden variables and hold information that identifies the class to which the object belongs. This information is usually a pointer to the class's virtual function table (an array describing the virtual function entries), and is correctly initialized in the class's constructor. And the virtual function call is
As shown in FIG. 7, reference to a → reference of pointer * a → reference of virtual function table by hidden variable → reference of virtual function index, jump to the virtual function entry and jump to the virtual function entity Implemented as a double jump.

The problem is that the address of the virtual function table is different for each program. This relationship is shown in FIG. 8, where the class information of an object generated by a certain program may look like a pointer pointing to a place completely unrelated to the actual virtual function table when viewed from another program. The result is that whatever happens, from system down to seemingly normal operation. Therefore, virtual functions cannot be used for shared objects at all.

An object of the present invention is to provide a shared memory system in which a shared object having a virtual function is stored and a virtual function can be called from the shared object.

[0019]

According to the present invention, a virtual function of a shared object can be used by fixing an address of a virtual function table, and has the following features.

In a shared memory system in which a plurality of application processes share an object of a class having a virtual function of an object-oriented system, an address of a virtual function table of each application process for referring to an object of a class having the virtual function It is characterized by having the same space.

Further, the class of the shared object is created by a shared library having a fixed address so that the address space of each process is the same.

[0022]

DESCRIPTION OF THE PREFERRED EMBODIMENTS In the embodiment of the present invention, as shown in FIG. 1, the addresses of the virtual function tables of processes 1 and 2 are the same for all programs sharing an object.

As shown in FIG. 2, this is realized by creating a shared object class having a virtual function as a shared library having a fixed load address.

For example, MS-Vi of Windows NT
In the C ++ environment, a class having a virtual function is loaded into a DLL (Dynamic Lin) with a fixed load address.
kLibrary). DLL is specified in the project by specifying the link as / base: xxxx
The base address is specified by xx (xxxxxx is a specific address), and relocation (address relocation) is prohibited by / fixed.

As a setting method in the screen setting, a base address is set as shown in FIG. 3 and relocation is prohibited (/ f
fixed) is not included in the setting items on the screen.
Write and set directly to the n option. Note that since writing cannot be performed while both the debug target and release to be set are selected, they are individually written and set.

[0026]

As described above, according to the present invention, since the address of the virtual function table is fixed, the reference structure by the pointer in the shared object system, address calculation is unnecessary, and the function of sharing the real memory is not impaired. It becomes possible to save a shared object having a virtual function and to call a virtual function from the shared object.

[Brief description of the drawings]

FIG. 1 is a table showing a virtual function table having a fixed address according to an embodiment of the present invention;

FIG. 2 is a table creation by a shared library in the embodiment.

FIG. 3 is a DLL setting screen according to the embodiment.

FIG. 4 refers to a shared object by a conventional reference.

FIG. 5 shows a conventional method of calculating a pointer at the time of loading.

FIG. 6 shows a conventional fixed address structure.

FIG. 7 is an explanatory diagram of a virtual function call and a virtual function table.

FIG. 8 is an explanatory diagram of an unknown address of a virtual function table.

Claims (2)

[Claims] 1. In a shared memory system in which a plurality of application processes share an object of a class having a virtual function of an object-oriented system, a virtual function table of each application process for referencing an object of a class having the virtual function. A shared memory system characterized by having the same address space. 2. The shared memory system according to claim 1, wherein the class of the shared object is created by a shared library having a fixed address so that the address spaces of the respective processes are the same.