JP2874571B2 - Memory management device - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a memory management device,
In particular, a multitasking OS (OperatingSystem)
m) relates to the memory management method.

[0002]

2. Description of the Related Art Conventionally, in this type of memory management system, when a plurality of types of memories having different access speeds are mounted and used in a computer system operated by a multitasking OS, the memory from each task is stored by the multitasking OS. Get requests are received in the order of earliest, and allocation to each of these plural types of memories is performed.

Here, the plural types of memories include a high-speed memory such as a local memory connected to a local bus, and a low-speed memory such as a main memory connected to a system bus.

That is, as shown in FIG. 9, the remaining capacity of the local memory is 100 KB and the remaining capacity of the main memory is 20 KB.
When a memory get request 23 of “memory type = local memory, memory capacity = 50 KB” is sent from task a at 0 KB, the multitask OS allocates 50 K of local memory to task a based on the memory get request 23.
B assignment, normal end notification 23 'indicating that the assignment has been completed
To notify task a. At this time, the remaining capacity of the local memory is 50 KB, and the remaining capacity of the main memory is 200 KB.
Remains.

Subsequently, when a memory get request 24 of “memory type = local memory, memory capacity = 15 KB” is sent from the task a, the multitask OS sends a local memory to the task a based on the memory get request 24. Is assigned to the task a by the normal end notification 24 '. At this time, the remaining capacity of the local memory is 35 KB, and the remaining capacity of the main memory is 2 KB.
It remains at 00 KB.

When a memory get request 25 of “memory type = main memory, memory capacity = 150 KB” is sent from the task a, the multitask OS sends the main memory to the task a based on the memory get request 25. 1
The task a is notified by the normal end notification 25 'that the 50 KB has been allocated and the allocation has been completed. At this time, the remaining capacity of the local memory is 35 KB, and the remaining capacity of the main memory is 50 KB.
KB.

Further, when a memory get request 26 of “memory type = main memory, memory capacity = 20 KB” is sent from the task c, the multitask OS assigns the main memory to the task c based on the memory get request 26. 2
0KB allocation, normal end notification 2 that allocation has been completed
At 6 ', task c is notified. At this time, the remaining capacity of the local memory is 35 KB, and the remaining capacity of the main memory is 30 KB.
B.

Further, from task c, “memory type =
When the memory get request 27 of “main memory, memory capacity = 10 KB” is sent, the multitask OS allocates 10 KB of the main memory to the task c based on the memory get request 27 and notifies the end of the normal termination of the allocation. At 27 ', the task c is notified. At this time, the remaining capacity of the local memory is 35 KB, and the remaining capacity of the main memory is 2 KB.
It becomes 0 KB.

In this state, from task i, “memory type =
When the memory get request 28 of “local memory, memory capacity = 80 KB” is sent, the multitask OS attempts to allocate 80 KB of local memory to the task i based on the memory get request 28, but the remaining amount of local memory is Is 35 KB, the memory allocation becomes impossible and the memory cannot be allocated. Therefore, a memory shortage error is notified to the task i by the abnormal end notification 28 ′.

Further, in this state, when a memory get request 29 of “memory type = main memory, memory capacity = 40 KB” is sent from the task n, the multitask OS sends the task n based on the memory get request 29. In this case, the main memory is allocated to 40 KB, but the remaining memory of the main memory is 20 KB, so that the memory cannot be allocated and the memory cannot be allocated. Therefore, the task n is notified of the memory shortage error with the abnormal end notification 29 ′.

[0011]

In the conventional memory management system described above, memory get requests from each task are received in the order of earliest and assigned to each of the plurality of types of memories. If the tasks that do not occupy the high-speed memory first, even if the task that needs high-speed operation tries to get the high-speed memory later, the task cannot get the high-speed memory, and the system throughput will decrease. May be invited.

Further, even if a certain task cannot operate without securing a high-speed memory of a certain capacity or more, it cannot be notified that a situation in which the system throughput cannot be guaranteed has occurred.

Furthermore, a memory get request from each task to the multitask OS is limited to one type of memory, and if a specified type of memory cannot be allocated, a memory to be allocated as a substitute cannot be specified.

Further, in the conventional memory management method,
Since the upper limit of the memory capacity that can be allocated to each task is not defined, only a specific task may occupy a specific type of memory.

An object of the present invention is to solve the above-mentioned problems and to provide a memory management device capable of allocating memory to each task in order of priority.

Another object of the present invention is to provide a memory management device which can prevent only a specific task from occupying a specific type of memory.

Still another object of the present invention is to detect and notify a memory shortage even when a certain task cannot operate because a certain amount of high-speed memory cannot be secured beyond a certain capacity and system throughput cannot be guaranteed. It is an object of the present invention to provide a memory management device capable of performing such operations.

[0018] Still another object of the present invention is to provide:
It is an object of the present invention to provide a memory management device that can allocate another memory as an alternative when a specified type of memory is not allocated.

[0019]

The memory management apparatus according to the present invention SUMMARY OF] is a memory management unit which performs assignment to a plurality of types of memories each having different access speed to the memory get requests from a plurality of tasks, the Task is memory
Information indicating whether or not to perform
The memory get flag to be stored correspondingly, and the task
Information indicating whether all memory get requests have been issued
Commit members stored for each of the plurality of tasks
Flag and memory get request from the plurality of tasks
When assigning to each of the above-mentioned types of memory
The memory get flag and the commitment flag
Detecting means for detecting whether all of the memory get requests have been issued from each of the tasks for performing the memory get based on the contents of each of the memory get requests, and detecting that all of the memory get requests have been issued by the detecting means. Allocating means for allocating a memory to each of the plurality of tasks based on priority information which is given to the memory get request of each of the plurality of tasks when the request is issued and indicates a priority to the requested memory.

In another memory management device according to the present invention, in addition to the above configuration, the sum of priority information given at the time of a memory get request to a memory allocated to each of the plurality of tasks is provided to each of the plurality of tasks. Means for determining whether or not a preset initial value of the priority for the memory has been exceeded; and means for inhibiting allocation of memory to the task when it is determined that the initial value of the priority has been exceeded. ing.

In another memory management device according to the present invention, in addition to the above-described structure, the memory management device may be configured to determine whether an assigned amount of each of the plurality of tasks for each type of memory exceeds an upper limit predetermined for each type of memory. Means for determining whether or not the task has exceeded the upper limit, and means for inhibiting allocation of a memory of a type corresponding to the upper limit to the task when it is determined that the upper limit has been exceeded.

Still another memory management device according to the present invention, in addition to the above configuration, is such that the quota of each of the plurality of tasks for each type of memory satisfies a lower limit predetermined for each type of memory. Means for determining whether or not the task has been performed, and means for suppressing processing of the task when it is determined that the lower limit is not satisfied.

[0023] Yet another memory management device according to the invention, in addition to the above arrangement, assigned to every designated candidate for designating a memory target is given to the request and the request destination of the type of memory of said plurality of tasks each Means for determining whether the assignment is possible, means for allocating to the type of memory designated by the next designation candidate when the assignment is determined to be impossible, and all designation candidates added to the memory get request Means for suppressing the allocation of memory to the task when it is determined that allocation to the task is impossible.

[0024]

When allocating a memory get request from a plurality of tasks to each of a plurality of types of memories having different access speeds, when all the memory get requests are requested from each of the plurality of tasks, the memory of each of the plurality of tasks is used. A memory is allocated to each of a plurality of tasks based on a cost assigned to the get request and indicating a priority to the memory of the request destination.

Further, when it is determined that the total cost given at the time of a memory get request to the memory allocated to each of the plurality of tasks exceeds the ownership cost preset for each of the plurality of tasks, the memory for the task is determined. Suppress assignments.

Further, when it is determined that the allocated amount of each memory type of each of the plurality of tasks exceeds an upper limit predetermined for each type of memory, the allocation of the memory of the type corresponding to the upper limit to the task is performed. Deter. Thus, it is possible to prevent only a certain task from occupying a specific type of memory.

When it is determined that the allocated amount for each memory type of each of the plurality of tasks does not satisfy the lower limit predetermined for each memory type, that is, when it is determined that the allocated amount is less than the lower limit, Stop the operation of. As a result, if a certain task cannot secure a certain type of memory over a certain amount, it becomes possible to detect and notify that the memory is insufficient when the system cannot be established because the system throughput cannot be secured.

It is determined whether or not allocation is possible for each designated candidate assigned to a memory get request of each of a plurality of tasks and specifying the type of memory to which the request is made. If it is determined that allocation is impossible, the next designated candidate is determined. Is allocated to the type of memory specified by the above, and when it is determined that allocation to all the specified candidates added to the memory get request is impossible, the allocation of memory to the task is suppressed. Thus, when the type of memory requested by a certain task cannot be obtained due to lack of capacity or the like, it is possible to allocate the memory to an alternative type of memory instead of not allocating the memory at all.

[0029]

Next, an embodiment of the present invention will be described with reference to the drawings.

FIG. 1 is a block diagram showing the configuration of one embodiment of the present invention. In the figure, a memory management device according to an embodiment of the present invention includes a memory allocation control unit 1, an allocation request receiving unit 2, an allocation determining unit 3, a cost determining unit 4, a memory capacity determining unit 5, an upper limit determining unit. Unit 6 and lower limit determination unit 7
And a memory management table 8.

Upon receiving allocation request information such as a memory get request from each task (not shown) and a commitment declaration for notifying the end of the transmission of the memory get request, the memory allocation control unit 1 allocates the allocation request information to the allocation request receiving unit. Send to 2. Further, the memory allocation control unit 1 controls each unit, and allocates and notifies various memories to each task in response to a determination result or the like from each unit.

Upon receiving the allocation request information from the memory allocation control unit 1, the allocation request receiving unit 2 registers the allocation request information in the memory management table 8.

When all the memory get requests from each task are registered in the memory management table 8, the allocation determination unit 3 determines the priority of each memory get request based on the allocation request information registered in the memory management table 8. Judgment and allocation to various memories are performed in order of priority.

In this case, the assignment determining unit 3 assigns to various memories in each task based on the priority (hereinafter referred to as cost) set according to the importance of the memory get request at the time of designing. Here, the cost is set in consideration of, for example, the access speed of processing performed based on the allocated memory and the access speed of various memories, and is calculated from a relational expression between the access speed of processing and the access speed of memory. It is also possible.

The cost judging section 4 judges whether or not the balance of the ownership cost set in advance for each task is sufficient to pay the cost indicating the degree of request for the memory get request for the allocated memory. That is, the cost determination unit 4 subtracts the payment cost from the ownership cost stored in the memory management table 8 every time memory allocation is performed, and performs memory allocation when the payment cost cannot be reduced due to insufficient balance of the ownership cost. The memory allocation control unit 1 is notified that there is no memory.

Here, the cost of ownership means the cost for each memory get request calculated according to what kind of memory, at what priority, and how much capacity should be allocated at the time of task design. This is the total value.

The memory capacity determination unit 5 determines whether or not memory can be allocated to the memory get request based on the remaining memory capacity allocated for each memory get request.

The upper limit value judging section 6 judges whether or not the memory allocation amount for each memory get request exceeds an upper limit value which can be allocated and set in advance for each type of memory. That is,
The upper limit determination unit 6 subtracts the upper limit stored in the memory management table 8 every time a memory is allocated, and when the upper limit cannot be subtracted, notifies the memory allocation control unit 1 not to allocate memory to the task.

The lower limit determining unit 7 determines whether or not the memory allocation amount for each memory get request is set in advance for each task, and whether the lower limit for each type of memory required at the minimum for operation is secured. judge. In other words, the lower limit determining unit 7 subtracts the lower limit of the memory management table 8 every time memory is allocated, and stops the operation of the task whose subtraction result remains positive when all the allocations are completed. This is notified to the assignment control unit 1 to prevent operation without securing the system throughput.

Note that the memory management device configured as described above can be realized by a program in the multitask OS. Hereinafter, the multitask OS includes a memory management device that performs the above-described processing.

FIG. 2 is a diagram showing the configuration of the memory management table 8 of FIG. In the figure, the memory management table 8 has a memory get flag 8b, a commitment flag 8c, a cost of ownership 8d, a memory allocation capacity upper limit 8e, and a memory allocation capacity lower limit corresponding to the task number 8a of each task. The value 8f is stored.

The memory get flag 8b is a flag for indicating whether or not the task is a task for performing a memory get, and has a value indicating whether there is a memory get or no memory get. This memory get flag 8b
Is determined when the task is loaded into memory.

The commitment flag 8c is a flag for indicating whether or not the task has made all memory get requests and has issued a commitment declaration to the multitask OS (not shown). Or uncommitted. The initial value of the commitment flag 8c is uncommitted.

The ownership cost 8d represents the current ownership value of the cost paid when the task issues a memory get request to the multitask OS, and the initial value is SG (Sys
(Tem Generator).

The memory allocation capacity upper limit 8e indicates the upper limit of the memory capacity for each type of memory that can be allocated to the task by the multitask OS, and the initial value is a value determined by SG. The memory allocation capacity upper limit 8e is managed for each memory type from the memory allocation capacity upper limit 8e-1 of the memory type 1 to the memory allocation capacity upper limit 8en of the memory type n.

The memory allocation capacity lower limit value 8f represents the lower limit value of the memory capacity for each type of memory required by the task at a minimum, and the initial value is a value determined by SG. The memory allocation capacity lower limit 8f is managed for each memory type from the memory allocation capacity lower limit 8f-1 of the memory type 1 to the memory allocation capacity lower limit 8e-m of the memory type m.

When each task issues a memory get request to the multitask OS, the task pays a cost to indicate the degree of memory request of the memory type to the multitask OS, and issues all memory get requests. At the time of completion, a commitment declaration is issued to the multitask OS.

The multitask OS does not allocate memory each time a memory get request is received from each task, but receives a commitment declaration from all tasks whose memory get flag 8b has a memory get. To start allocating memory.

When the multitask OS allocates memory, memories of the same memory type are allocated in order from the task that paid more cost. still,
The multitasking OS has a task
The payment cost is subtracted from the ownership cost 8d. When the ownership cost 8d of a certain task is insufficient to reduce the payment cost due to insufficient balance, the multitask OS does not allocate memory.

When allocating memory as described above, if the cost of owning a certain task is extremely high, only that task may occupy a memory of a certain memory type. Therefore, an upper limit value of the memory capacity that can be allocated for each memory type is provided corresponding to each task so that only a specific memory type is not occupied. The upper limit value 8e is subtracted, and when the subtraction becomes impossible, no memory is allocated to the task.

If the system throughput cannot be secured unless a certain task can secure a memory of a certain memory type or more, a memory larger than the minimum memory capacity required by the task is allocated by the above-mentioned memory allocation. We cannot guarantee that they have been secured.

Therefore, in order to stop the operation of the task when the memory of a certain memory type cannot be secured beyond a certain fixed capacity, the lower limit of the minimum memory capacity required for each memory type corresponding to each task is set. And multitasking O
S decrements the lower limit every time memory is allocated, stops the operation of the task whose subtraction result remains positive when all allocations are completed, and prevents the task from operating without securing system throughput.

Further, when a certain task issues a memory get request to the OS, if only one kind of memory type can be designated, another task pays more cost to the memory of that memory type. In some cases, the memory may not be allocated due to the bid for the multitask OS, and the memory of the specified memory type may not be allocated even when the memory allocation capacity upper limit 8e is exceeded.

Therefore, when each task issues a memory get request to the multitask OS, the payment cost can be specified for each of a plurality of memory types from the first memory to the nth memory. If the OS cannot allocate the memory according to the i-th desired memory type, the OS performs the memory allocation according to the (i + 1) th desired memory type.

FIGS. 3 to 7 are flowcharts showing the operation of one embodiment of the present invention. The operation of the embodiment of the present invention will be described with reference to FIGS.

When the memory allocation control unit 1 starts the memory allocation process, it first determines whether commitment declarations have been received from all tasks (step S1 in FIG. 3). When determining that commitment declarations have been received from all tasks, the memory allocation control unit 1 determines whether there is a memory get request in a memory get request queue (not shown), that is, whether the memory get request queue is empty. (Step S2 in FIG. 3).

When the memory allocation control unit 1 determines that the memory get request queue is empty, the lower limit determination unit 7 checks whether there is a task below the memory allocation capacity lower limit 8f. If there is a task lower than the above, the operation of the task is stopped (step S in FIG. 3).
6), end the process.

When the memory allocation control unit 1 determines that there is a memory get request in the memory get request queue, the allocation control unit 3 takes out the memory get request with the highest unit price from the memory get request queue (step S in FIG. 3).
3). At this time, the memory allocation control unit 1 makes the cost determination unit 4
It is determined whether the balance of d is sufficient (step S in FIG. 3).
4).

When the cost deciding section 4 decides that the balance of the ownership cost 8d of the task of the memory get request source is not sufficient, the memory allocation control section 1 notifies the task of the memory get request source of the lack of ownership cost error. (Step S5 in FIG. 3), and the process returns to Step S2.

When the cost determining unit 4 determines that the cost of the memory-request-requesting task has a sufficient balance of the ownership cost 8d, the memory allocation control unit 1 determines the amount of memory for which the memory-request is requested. It is determined whether the capacity is sufficient (step S12 in FIG. 5).

When the memory capacity determination unit 5 determines that the memory capacity requested for memory acquisition is sufficient, the memory allocation control unit 1 determines whether the upper limit value determination unit 6 has exceeded the memory allocation capacity upper limit 8e. A determination is made (step S13 in FIG. 5). The memory allocation control unit 1 includes an upper limit value determination unit 6
When it is determined that the memory allocation capacity does not exceed the upper limit 8e, the memory is allocated (step S14 in FIG. 5), and the process returns to step S2.

When the upper limit value judging unit 6 judges that the memory allocation control unit 1 has exceeded the memory allocation capacity upper limit 8e, the memory allocation control unit 1 issues a memory allocation upper limit error notification to the task that has requested the memory get (see FIG. 5 Step S15), and return to Step S2.

When the memory capacity determining unit 5 determines that the memory capacity requested for the memory get is not sufficient, the memory allocation control unit 1 determines whether there is a next memory type candidate (step in FIG. 7). S17).

When the memory allocation control unit 1 determines that there is no next memory type candidate, the memory allocation control unit 1 issues a memory shortage error notification to the task requesting the memory get (step S in FIG. 7).
18), and return to step S2.

When determining that there is a next memory type candidate, the memory allocation control unit 1 sets the memory type as the next candidate (step S19 in FIG. 7) and returns to step S4 to determine the cost of the next candidate. .

On the other hand, if the memory allocation control unit 1 determines that no commitment declaration has been received from all tasks, it waits for an event (step S7 in FIG. 4) and determines that the request from the task is a commitment declaration (step S7 in FIG. 4). S8), the commitment flag 8c of the corresponding task is turned on (step S9 in FIG. 4), and step S1 is performed.
Return to

When the memory allocation control unit 1 determines that the request from the task is a memory get request (step S10 in FIG. 4), the memory allocation request is queued in the memory get request queue (step S11 in FIG. 4). Return to S1.

Further, when the memory allocation control unit 1 determines that the request from the task is another process, it passes the request to the multitask OS to perform another process (step S6 in FIG. 6).
16) Return to step S1.

FIG. 8 is a diagram showing a memory allocation sequence in the multitask OS in one embodiment of the present invention. The memory allocation sequence in one embodiment of the present invention will be described with reference to FIG. In this system, there are two types of memory, a local memory (high-speed memory) and a main memory (low-speed memory), and the memory capacity that can be allocated to each task is 100 KB for the local memory and 200 KB for the main memory.

Each task issues a memory get request to the multitask OS by designating a memory type, a payment cost (unit price) per 1 KB, and a memory capacity. In the figure, “→” in the memory type and unit price indicates the order from the first desired memory type and unit price to the next desired memory type and unit price.

The task a is described as “first desired memory type = local memory, first desired unit price = 7, second desired memory type = main memory, second desired unit price = 5, memory capacity =
50 KB "memory get request 12 and" first desired memory type = local memory, first desired unit price = 9, second
Desired memory type = main memory, second desired unit price =
5, memory capacity = 15KB ”memory get request 13
And a memory get request 14 of “first desired memory type = main memory, first desired unit price = 3, memory capacity = 150 KB”, and then a commitment declaration (co
issue) 15 to the multitask OS.

Task c is “first desired memory type = main memory, first desired unit price = 4, memory capacity = 20K
B "and a" first desired memory type = main memory, first desired unit price = 2, memory capacity =
After issuing the memory get request 17 of "10 KB",
Issues a commitment declaration 18 to the multitask OS.

The task i is “first desired memory type = local memory, first desired unit price = 10, memory capacity = 80
After the memory get request 19 of “KB” is issued, the commitment declaration 20 is issued to the multitask OS.

The task n is “first desired memory type = main memory, first desired unit price = 8, memory capacity = 40K
After issuing the memory get request 21 of "B", a commitment declaration 22 is issued to the multitask OS.

In FIG. 8, since the task b does not get the memory, the task b does not issue the memory get request and the commitment declaration.

As described above, the tasks a,
Commitment declarations 15, 18, 2 from c, i, n
When 0 and 22 are issued, the multitask OS starts a memory allocation process and requests the memory get requests 12 to 14 and 1.
The memory get request having the highest unit price is taken out of 6, 17, 19, and 21.

In this case, since the memory get request having the highest unit price is the memory get request 19 from the task i, the multitask OS allocates 80 KB of the local memory to the task i based on the memory get request 19, and indicates that the allocation has been completed. The task i is notified by the normal end notification 19 '. At this time, the remaining capacity of the local memory is 20 KB.

As described above, the first memory get request is the memory get request 12 from the task a, but the first allocation is made from the memory get request 19 from the task i, and the memory allocation is early. Not in order,
The order of the unit price is high.

The memory get request having the next highest unit price after the memory get request 19 is the memory get request 13 from the task a.
Therefore, the multitask OS allocates 15 KB of the local memory to the task a based on the memory get request 13, and notifies the task a of the completion of the allocation to the task a with the normal end notification 13 '. At this time, the remaining capacity of the local memory is 5 KB.

For task a, a memory get request 12
Is a memory get request issued earlier than the memory get request 13. Since the memory is also allocated in the order of higher unit price, not earlier, the tasks a, c, i, n In designing the memory get request processing, the unit price may be set according to the importance, and it is not necessary to consider the order in which the memory get requests are issued.

A memory get request having the next highest unit price after the memory get request 13 is a memory get request 21 from task n.
Therefore, the multitask OS allocates 40 KB of the main memory to the task n based on the memory get request 21 and notifies the task n of the completion of the allocation with the normal end notification 21 '. At this time, the remaining amount of the main memory is 160 KB.

A memory get request having the next highest unit price after the memory get request 21 is the memory get request 12 from the task a.
Therefore, the multitask OS attempts to allocate 50 KB of the local memory to the task a based on the memory get request 12. However, since the remaining amount of the local memory is 5 KB and the memory cannot be allocated, the multi-task OS allocates 5 KB to the second desired main memory.
0KB allocation, normal end notification 1 that allocation has been completed
2 'notifies task a. At this time, the remaining amount of the main memory is 110 KB.

The memory get request having the next highest unit price after the memory get request 12 is the memory get request 16 from the task c.
Therefore, the multitask OS allocates 20 KB of the main memory to the task c based on the memory get request 16, and notifies the task c of the completion of the allocation with the normal end notification 16 '. At this time, the remaining amount of the main memory is 90 KB.

The memory get request having the next highest unit price after the memory get request 16 is the memory get request 14 from the task a.
Therefore, the multitask OS attempts to allocate 150 KB of the main memory to the task a based on the memory get request 14, but the remaining memory of the local memory is 5 KB and the memory cannot be allocated. The task a is notified by the notification 14 '.

A memory get request having the next highest unit price after the memory get request 14 is a memory get request 17 from the task c.
Therefore, the multitask OS attempts to allocate 10 KB of the main memory to the task c based on the memory get request 17, and the ownership cost balance of the task c at this time is 2 * 1.
If 0 is less than 20, memory allocation becomes impossible due to an ownership cost shortage error, and the memory allocation failure is notified to the task c by the ownership cost shortage error notification 17 '.

In the above description, when an error occurs without allocating memory when the memory allocation capacity upper limit 8e corresponding to each task is exceeded, or when a task operation is stopped when the memory allocation capacity lower limit 8f falls below the memory allocation capacity lower limit 8f. However, it is possible to perform these checks when actually allocating memory after receiving commitment declarations from all tasks that request memory get.

As described above, when a memory get request from a plurality of tasks is assigned to each of a plurality of types of memories having different access speeds, a plurality of memory get requests are issued when all the memory get requests are issued from each of the plurality of tasks. By allocating memory to each of a plurality of tasks based on the cost assigned to each task's memory get request and indicating the priority to the requested memory, memory can be allocated to each task in order of priority. .

Further, when it is determined that the total cost given when a memory get request is made to the memory allocated to each of the plurality of tasks exceeds the ownership cost preset for each of the plurality of tasks, the memory for the task is determined. Can prevent a specific task from occupying a specific type of memory.

Further, when it is determined that the allocation amount for each memory type of each of the plurality of tasks exceeds an upper limit predetermined for each memory type, the allocation of the memory of the type corresponding to the upper limit to the task is performed. Can prevent only a specific task from occupying a specific type of memory.

Further, when it is determined that the allocated amount of each of the plurality of tasks for each type of memory does not satisfy the lower limit predetermined for each type of memory, that is, it is determined that it is below the lower limit. Sometimes, by stopping the operation of a task, a task can not operate because it cannot secure high-speed memory beyond a certain amount and a system throughput can not be guaranteed. it can.

Further, it is determined whether or not allocation is possible for each designation candidate assigned to the memory get request of each of the plurality of tasks and specifying the type of memory of the request destination. By allocating to the type of memory specified by the next specified candidate, and by allocating memory to the task when it is determined that allocation to all specified candidates added to the memory get request is not possible, If no such memory type is allocated, another memory can be allocated as an alternative.

[0092]

As described above, according to the memory management device of the present invention, when a memory get request from a plurality of tasks is assigned to each of a plurality of types of memories having different access speeds, a plurality of tasks are allocated. When it is detected that all the memory get requests have been issued from each, the memory allocation to each of the plurality of tasks is performed based on the priority information which is given to the memory get request of each of the plurality of tasks and indicates the priority to the requested memory. By doing so, there is an effect that memory allocation to each task can be performed in order of priority.

According to another memory management device of the present invention, the sum of the priority information given at the time of a memory get request to the memory allocated to each of the plurality of tasks is determined by the priority over the memory preset for each of the plurality of tasks. When it is determined that the degree exceeds the initial value, by suppressing the memory allocation to the task, it is possible to prevent a specific task from occupying a specific type of memory.

According to another memory management device of the present invention, it is determined whether or not the quota of each of the plurality of tasks for each type of memory exceeds an upper limit predetermined for each type of memory. By suppressing the allocation of the memory of the type corresponding to the upper limit value for the task when it is determined that the number of the tasks exceeds the limit, it is possible to prevent the specific task from occupying only the memory of the specific type. is there.

According to still another memory management apparatus of the present invention, it is determined whether or not the allocated amount of each of a plurality of tasks for each type of memory satisfies a lower limit predetermined for each type of memory. When it is determined that the lower limit is not satisfied, the processing of the task is suppressed, so that a certain task cannot operate because a certain amount of high-speed memory cannot be secured or more, and the system throughput cannot be guaranteed. However, there is an effect that the memory shortage can be detected and notified.

According to still another memory management device of the present invention, it is determined whether or not allocation is possible for each designated candidate which is assigned to a memory get request of each of a plurality of tasks and specifies the type of requested memory. Then, when it is determined that allocation is impossible, the allocation to the type of memory specified by the next specified candidate is performed, and when it is determined that allocation to all specified candidates added to the memory get request is impossible, the task is performed. By suppressing the allocation of memory for
When a specified type of memory is not allocated, another memory can be allocated as an alternative.

[Brief description of the drawings]

FIG. 1 is a block diagram showing the configuration of an embodiment of the present invention.

FIG. 2 is a diagram illustrating a configuration of a memory management table in FIG. 1;

FIG. 3 is a flowchart showing the operation of one embodiment of the present invention.

FIG. 4 is a flowchart showing the operation of one embodiment of the present invention.

FIG. 5 is a flowchart showing the operation of one embodiment of the present invention.

FIG. 6 is a flowchart showing the operation of one embodiment of the present invention.

FIG. 7 is a flowchart showing the operation of one embodiment of the present invention.

FIG. 8 is a diagram showing a memory allocation sequence in the multitask OS in one embodiment of the present invention.

FIG. 9 is a diagram showing a memory allocation sequence in a multitask OS in a conventional example.

[Explanation of symbols]

 Reference Signs List 1 memory allocation control unit 2 allocation request receiving unit 3 allocation determining unit 4 cost determining unit 5 memory capacity determining unit 5 6 upper limit determining unit 7 lower limit determining unit 8 memory management table 8a task number 8b memory get flag 8c commitment flag 8d Cost of ownership 8e Upper limit of memory allocation capacity 8f Lower limit of memory allocation capacity

Claims (6)

(57) [Claims] 1. A memory management device for allocating a memory get request from a plurality of tasks to each of a plurality of types of memories having different access speeds, wherein the task is a memory
Information indicating whether or not to perform a morriget is stored in the plurality of tasks.
A memory get flag to be stored for each
Indicates whether the disk has issued all memory get requests
A committer for storing information corresponding to each of the plurality of tasks;
And the memory flag from the plurality of tasks.
Assignment to each of the multiple types of memory
When performing, the memory get flag and the commit
Detecting means for detecting whether or not all of the memory get requests have been issued from each of the tasks for performing the memory get based on the contents of each of the memory flags, and wherein all of the memory get requests have been issued by the detecting means. Allocating means for allocating memory to each of the plurality of tasks based on priority information which is added to the memory get request of each of the plurality of tasks when it is detected that the plurality of tasks have been received, and indicates priority to the requested memory. A memory management device, characterized in that: 2. A method according to claim 1, wherein a sum of priority information given at the time of a memory get request to a memory assigned to each of said plurality of tasks exceeds an initial value of priority for said memory preset for each of said plurality of tasks. 2. The memory management device according to claim 1, further comprising: means for determining whether or not the priority has been exceeded, and means for suppressing allocation of memory to the task when it is determined that the priority has exceeded the initial value. 3. A means for judging whether an assigned amount of each of the plurality of tasks for each type of memory has exceeded an upper limit predetermined for each type of memory, and judging that the upper limit has been exceeded. 3. The memory management device according to claim 1, further comprising: means for suppressing allocation of a type of memory corresponding to the upper limit to the task when the task is performed. 4. A means for determining whether or not the quota of each of the plurality of tasks for each type of memory satisfies a lower limit predetermined for each type of memory, and satisfies the lower limit. 4. The memory management device according to claim 1, further comprising: means for stopping the operation of the task when it is determined that the task is not present. 5. A means for judging whether or not assignment is possible for each designation candidate assigned to a memory get request of each of the plurality of tasks and designating a type of requested memory, and judging that the assignment is impossible Means for allocating to the type of memory specified by the next specified candidate when the allocation is made, and allocating memory to the task when it is determined that allocation to all specified candidates added to the memory get request is impossible. The memory management device according to claim 1, further comprising a suppression unit. 6. The memory according to claim 1, wherein the priority information is assigned to each memory get request based on a priority order for each memory get request and a priority order for each type of memory. The memory management device according to any one of claims 1 to 4.