JPS61123953A - Virtual object control method - Google Patents

Abstract

PURPOSE:To make access without considering the memory position, by making the system process the identification whether the object exists in main memory or in secondary memory, and the transfer of the object from the main memory to the secondary memory. CONSTITUTION:In case the object is on the main memory, the system knows it by referring to an object management table 4, and make an access according to that address. In case the object is on th3e secondary memory and there is enough space in the main memory, the system first refers to the object management table 4. In this case, since the IC information value is NIL, the system refers to BL information. As the block number which indicates the storage position of the data of object C1 of the secondary memory is stated in the BL information, the system tries to transfer the object from the secondary memory to the main memory. If there is adequate space in the main memory, the object is transferred to the main memory from the corresponding area of the secondary memory, and its head address is written on the object administration table 4.

Description

[Detailed Description of the Invention] [Industrial Application Field] The present invention relates to an implementation method of object-oriented programming, and when handling a large number of objects that cannot be stored in main memory, This invention relates to a method for virtually managing the movement of objects between main memory and secondary memory by storing objects in secondary memory.

[Conventional technology]

In conventional object-oriented programming implementation methods, objects (combinations of data and procedures) are always stored in main memory, and therefore the number and thickness of objects that can be stored depend on main memory. Therefore, when handling large objects that cannot be stored in the main memory area, store the object in secondary memory and transfer the necessary parts to main memory. It is necessary to adopt a method of expansion.

[Problem that the invention seeks to solve]

Conventionally, when handling a large object like this, you have to be aware of whether the target object is in main memory or secondary memory, which makes programming complicated and difficult to create. There was a problem with this.

The present invention performs "object virtualization" by treating objects stored in secondary storage in the same way as objects stored in main storage, and also performs LRU management when flushing to secondary storage. To do this,
The purpose is to provide a method that can efficiently access large-scale object systems.

[Means for summarizing the problem]

According to the present invention, this object is achieved by providing a data processing apparatus having an object-oriented programming function, in which each object exists in the main memory or in the secondary memory. means for storing an address in main memory or secondary memory where the object exists, and means for storing old and new accesses from a program for each object in the main memory. , when accessing an object from a program, since the object is stored in secondary memory, when the system attempts to read it and store it in main memory, # is stored in main memory.
If there is no free space to accommodate the object, the object currently in main memory that has been most recently accessed by the program is moved to secondary storage, and the program accesses the free space created by this. This is achieved by a virtualized object control method characterized by storing objects to be processed.

[For production]

In the above-mentioned method, it is possible to identify whether an object exists in main memory or secondary memory, and to transfer an object that is most recently accessed from a program (oldest and existing in main memory) to secondary memory. In addition, the system (control program of the data processing device) performs all the necessary processing such as reading out the necessary object from secondary storage, storing it in the main memory, and all the necessary processing related to these. Programming can be easily performed because access can be made without considering whether the data exists in main memory or secondary memory.

〔Example〕

Regarding the operation of the present invention, when there is a request to access an arbitrary object in a program, ``how the system finds the object data and passes it to the program'' and ``how the system finds the data of the object and passes it to the program'' and ``Which object should be extracted to secondary storage when the free space becomes small?'' will be explained based on the drawings of the embodiment.

FIG. 1 is a diagram explaining the operation of one embodiment of the present invention, (a
) is when the object is in main memory, (b) is when the object is in secondary memory but there is free space in main memory, and (C) is when the object is in secondary memory and there is free space in main memory. 1 indicates the program section of the main memory, 2 indicates the data section of the main memory, 3 indicates the program module, 4 indicates the object management table, and 5I to 5
．． C is an object, 6 is an LRU management table,
7 is secondary storage, 8 is a block for storing objects, 1
2 represents the free space in the main memory.

To explain Fig. 1 (engineering), in this case, it is sufficient to directly bring the object in the main memory, but in this case, when a program requests access to object 5, the system uses object management table 4. By referring to , the object knows that it is in main memory, and also obtains its address and accesses it.

That is, as shown in FIG. 2, the object management table includes OBJ information 9 (address (G) of the object on the main memory) and IO information 10 (information indicating whether the object is on the main memory (H)). )) and BL information 11
(Block number (1) of the location where the object is stored on the secondary memory) etc. exists, and in the above case, the work 0 information 10 is T (indication that the object is on the main memory) Since the OBJ information 9 contains the address of the data storage location for object 5, the data for object 5s (Os) is obtained and passed to the program module. At this time, the object name CI is added to the left end of the L-U management table 6 as the latest accessed object.

The solid arrows with prefixed numbers in FIG. 1 indicate access routes, and the numbers in circles indicate the chronological order of access. The same applies to FIGS. 1(b) and 1(c) which will be described later, and furthermore, in these drawings, the movement of objects is indicated by two parallel solid lines and arrows.

Next, a case where the object is in the secondary storage and there is sufficient free space in the main storage will be explained using FIG. 1(b).

First, the system refers to the object management table 4. - In this case, the value of the IC information is NIL (indicating that the object is not in the main memory), so the BL information is looked at without looking at the OBJ information. Since the BI information describes the block number representing the storage location of the data of the object OI on the secondary storage, the system attempts to read the object from the secondary storage onto the main storage.

At this time, before reading, it is checked whether there is enough free space on the main memory. If there is enough free space, the BL information will be used to store objects in secondary storage from the location corresponding to Os.
The data is read into the main memory, and its start address is written as the value of the OBJ information of object 01 in the object management table 4. (■, ■) Furthermore, the object name Os is added to the left end of the LRU management table D as the latest access object. Finally this object)01
data is passed to program module 3. (■) Next, a case where the object is in the secondary storage and there is not enough free space in the main storage will be described using FIG. 1(0).

First, the system refers to the object management table 4. (■) In this case, the value of the work 0 information is NIL, so the OB
Without looking at the J information, the block number representing the storage location of the data of object 01 on the secondary storage is obtained from the BL information. Next, it is checked whether there is enough free space on the main memory. In this case, there is not enough free space, so the object cannot be read from secondary storage immediately. Therefore, some objects are flushed to secondary storage until there is enough free space on main storage. The determination of objects to be purged to secondary memory is determined by L
This is done through RU (Least Recently Used) management. That is, the system considers newly accessed objects as important, olderly accessed objects as less important, and unaccessed objects as the least important. For this LRU management, LRU
A key called management table 6 is prepared.In this LRU management table 6, the names of all objects in the main memory are arranged in a straight line, and objects that are newly accessed are arranged from right to left in the figure. to manage. Therefore, the object name of the latest access is added to the left end of table D, and the object of the oldest access at the right end is selected as the first object to be flushed to secondary storage. In this way, when an object to be flushed to the secondary memory is selected, the data of that object is flushed to the secondary memory. In order to clear this out, first,
Based on the object name, refer to the object management table 4 and view the BL information. For objects that have never been flushed to secondary memory, the BL information value is NI.
Since it is L, select the block number of an unused block and press B
This is the value of L information. For objects that have been swept out before, the previous BL information is used as is.

When the diblock number is determined from the BL information, the address of the object to be flushed is determined from the value of the oBJ information, and the data is written to the specified block on the secondary storagec.
(■, ■) This object sweep operation is repeated until there is enough free space on the main memory, and when there is enough free space, object 0. Data is read into the main memory from the block corresponding to the block number of the BL information. (■,■
) The start address of the data of this read object is set to O of the object CI in the object management table 4.
Write the object name C8 as the value of BJ information and write it as the value of BJ information.
Add it to the left end of the RU management table 6 as the latest access object. Finally, the data of this object OX is passed to the program module 3. (■) As an application example of the present invention, for example, application to a knowledge representation system can be considered. A knowledge representation system is a system that expresses and utilizes knowledge related to a specific target field on a computer using each piece of knowledge as an element and the mutual relationships between each piece of knowledge. It can be expressed by adding In this case, knowledge is expressed as a network of objects, but if the knowledge becomes large-scale, it becomes difficult to store all of the objects in main memory.

In such a case, an appropriate method would be to virtualize the shiobjierito according to the present invention.

〔Effect of the invention〕

Since the present invention adopts a method of storing objects in both main memory and secondary memory, it is possible to secure a large storage area, so it is possible to handle large-scale object systems. Since objects are flushed out to the secondary storage using L/U management, the overhead associated with accessing the secondary storage can be kept low.

Furthermore, since the procedure for accessing an object during programming can be performed without being aware of whether the object is in the main memory or the secondary memory, it is easy to create a program, which is highly effective.

[Brief explanation of the drawing]

FIG. 1 is a diagram for explaining the operation of an embodiment of the present invention, and FIG. 2 is a diagram for explaining an object management table. １・・・・・・・・・Program Department, ２・・・・・・・・・
...Data section, 3...Program module,
4......Object management table, 51
~51...Object, 6...L
RU management table, 7...--Secondary memory,
8...Block for storing objects, 9...
・・・・・・OBJ information, 10・・・・・・・・・I
C information, 11...BL information, 12...
...Empty space store feather'--゛;:”.

Claims (1)

[Claims] In a data processing device equipped with an object-oriented programming function, it stores whether each object exists in main memory or secondary memory and the address in main memory or secondary memory where the object exists. and a means for storing the order of latest and old access from the program for each object existing on the main memory, and when the object is accessed from the program, the object is stored in the secondary memory. Therefore, when the system attempts to read this object and store it in main memory, if there is no free space on main memory to accommodate the object, the most recently accessed object from the program among the objects currently existing in main memory will be A virtualized object control method characterized by moving old objects to secondary storage and storing objects to be accessed by a program in the resulting empty area.