JP6423809B2 - Operating system, programming system, and memory allocation method - Google Patents

Description

  The present invention relates to an operating system executed in a multi-core environment in which processor cores are connected to each other, a programming system for constructing a system using the operating system, and a memory allocation method.

  In recent years, systems such as embedded products have become complex, and an increasing number of systems employ a multi-core processor having a plurality of processor cores in order to realize multiple functions. In such a multi-core environment, it is important to efficiently use resources by sharing a memory among processor cores and to increase processing speed by avoiding memory contention.

  By the way, such a system often includes a plurality of different types of memories, and there is a difference in the access speed of each memory. Therefore, it is important to appropriately allocate which memory is used depending on the contents of processing.

  However, since the developer of the application program does not always know the type of memory, it is desirable for the operating system to execute appropriate memory allocation. For example, when the application program requests a memory having a high access speed, it is conceivable that the operating system selects a memory having a high access speed and performs memory allocation from the memory.

  As described in Patent Document 1, in a system including a memory (primary cache) unique to each processor core, a memory having the fastest access speed for a certain processor core is a memory unique to the processor core. It is. Therefore, the memory with the fastest access speed changes depending on the processor core at the time of execution.

JP 2012-53817 A

  As described above, when the memory with the fastest access speed changes depending on the processor core at the time of execution, the operating system dynamically selects the memory with the fastest access speed to execute the memory allocation. If possible, it is possible to improve the efficiency of memory resources and the processing speed.

  On the other hand, when the application program developer knows the type of memory, there is a demand for acquiring memory from a specific memory. In this case, if the memory allocation can be executed from the specific memory specified by the application program without going through the dynamic selection by the operating system as described above, the degree of freedom in constructing the system is improved. To do.

  Then, switching between the above-mentioned “method of dynamically selecting a memory having a high access speed by the operating system to execute memory allocation” and “method of executing memory allocation from a specific memory specified by the application program” as described above Can be realized without changing the application program, it becomes easy to port the application program to an environment with different hardware resources (for example, when the system is ported to another environment with a different memory type, the application program is changed). Can also be transplanted without doing this).

  Therefore, according to the present invention, at the time of executing a program, the operating system can dynamically select a memory having a high access speed and execute the memory allocation, and can also execute the memory allocation from a specific memory designated by the application program. It is an object of the present invention to provide an operating system, a programming system, and a memory allocation method capable of realizing switching between the two memory allocation methods without changing an application program.

  The present invention has been made to solve the above-described problems, and is characterized by the following.

The invention according to claim 1 is an operating system that is executed in a multi-core environment in which a plurality of processor cores each having a local memory are connected to each other, and in which a memory acquisition API that can be called from an application program is mounted. A memory area creation unit that creates a plurality of memory areas according to the internal data that has been set, and a heap ID specified as an argument of the memory acquisition API, and performs memory allocation from the memory area associated with the heap ID A real memory for allocating the memory by directly specifying the memory area as the heap ID, the memory area including a core memory area related to a local memory of the plurality of processor cores ID and the core memory area The selected dynamically includes a virtual core ID to allocate memory, the definition of the heap ID is a rewritable by a user, the memory allocation unit, said real memory ID is designated When the memory acquisition API is called, memory allocation is executed from the memory area associated with the specified real memory ID, and when the virtual core ID is specified and the memory acquisition API is called, Memory allocation is executed from the core memory area related to a local memory of a processor core in which an application program that calls the memory acquisition API is executed.

  The invention according to claim 2 includes a cluster memory area linked to one or more core memory areas as the memory area in addition to the feature of the invention according to claim 1, and the heap ID. Including a virtual cluster ID for dynamically selecting the cluster memory area and allocating memory, and the memory allocating unit is configured such that when the virtual cluster ID is specified and the memory acquisition API is called, Specifying the core memory area related to the local memory of the processor core in which the application program that called the memory acquisition API is being executed, and executing memory allocation from the cluster memory area linked to the core memory area Features.

  The invention according to claim 3 includes a global memory area linked to one or more of the cluster memory areas as the memory area in addition to the features of the invention according to claim 2 described above, and the heap ID Including a virtual global ID for dynamically selecting the global memory area and allocating memory, and the memory allocating unit is configured such that when the virtual global ID is specified and the memory acquisition API is called, The global memory found by identifying the memory area related to the local memory of the processor core in which the application program that called the memory acquisition API is executed, and recursively tracing the memory area linked to the memory area Memory allocation is executed from the area.

  According to a fourth aspect of the present invention, in addition to the feature of the invention according to any one of the first to third aspects, the memory area creating unit creates a tree structure in the memory area, and the memory allocation unit When the memory allocation from the memory area specified by the heap ID fails, the memory allocation is executed from the upper memory area of the memory area.

According to a fifth aspect of the present invention, the operating system according to any one of the first to fourth aspects, a configuration file describing a relationship between the heap ID and the memory area, and the configuration file are read. An information generating means for generating the header file for the application program and the internal data for the operating system according to claim 1 , and a compiler for compiling the source code of the application program using the header file. It is characterized by providing.

According to a sixth aspect of the present invention, in a multi-core environment in which a plurality of processor cores each having a local memory are connected to each other, memory allocation for causing memory allocation to be executed when a memory acquisition API is called from an application program A method of creating a plurality of memory areas according to preset internal data, and referring to a heap ID specified as an argument of the memory acquisition API, and from the memory area associated with the heap ID And a step of allocating memory, including a core memory area related to a local memory of the plurality of processor cores as the memory area, and specifying the memory area directly as the heap ID. Real memory ID and the core memory area The selected dynamically includes a virtual core ID to allocate memory, the definition of the heap ID is a rewritable by a user, the real memory ID is designated by the memory acquisition for the API When called, the memory allocation is executed from the memory area associated with the specified real memory ID. When the virtual core ID is specified and the memory acquisition API is called, the memory acquisition API is set. Memory allocation is executed from the core memory area related to the local memory of the processor core in which the called application program is executed.

  The invention according to claim 7 includes, in addition to the feature of the invention according to claim 6, the memory area includes a cluster memory area linked to one or more core memory areas, and the heap ID Including a virtual cluster ID for dynamically selecting the cluster memory area and allocating memory. When the virtual cluster ID is specified and the memory acquisition API is called, the memory acquisition API is called. The core memory area related to the local memory of the processor core in which the application program is executed is specified, and memory allocation is executed from the cluster memory area linked to the core memory area.

  The invention described in claim 8 includes, in addition to the feature of the invention described in claim 7, the memory area includes a global memory area linked to one or more cluster memory areas, and the heap ID Including a virtual global ID for dynamically selecting the global memory area and allocating memory, and when the virtual acquisition ID is specified and the memory acquisition API is called, the memory acquisition API is called The memory area related to the local memory of the processor core in which the application program is executed is identified, and memory allocation is executed from the global memory area found by recursively tracing the memory area linked to the memory area. It is characterized by making it.

  In addition to the feature of the invention described in any of claims 6 to 8, the invention described in claim 9 creates a tree structure in the memory area, and starts from the memory area specified by the heap ID. When the memory allocation fails, the memory allocation is executed from the upper memory area of the memory area.

  The invention according to claim 1 or 6 is as described above, and when the real memory ID is specified and the memory acquisition API is called, the memory allocation is executed from the memory area associated with the specified real memory ID. I try to let them. For this reason, when it is desired to execute memory allocation from a specific memory designated by the application program, the memory acquisition API may be called by designating the real memory ID.

  When the virtual core ID is specified and the memory acquisition API is called, the memory allocation is executed from the core memory area related to the local memory of the processor core in which the application program that called the memory acquisition API is executed. I have to. For this reason, if the operating system wants to dynamically select a memory with high access speed (memory unique to the processor core) and execute memory allocation, the virtual core ID may be specified to call the memory acquisition API.

  In addition, since the two memory allocations described above are realized by the same memory acquisition API, the memory allocation method can be switched only by changing the definition of the heap ID without changing the application program. For example, if the definition of the heap ID is changed by rewriting the configuration file and the heap ID assigned to the virtual core ID is assigned to the real memory ID, the memory acquisition API is changed using the heap ID. The memory allocation method can be switched without changing the calling application program. In this case, before changing the definition of the heap ID, memory allocation is executed from the memory area unique to the processor core at the time of program execution. After changing the definition of the heap ID, the specific specified by the heap ID is performed. Memory allocation from the memory area is executed.

  The invention according to claim 2 or 7 is as described above, and when a virtual cluster ID is specified and a memory acquisition API is called, a processor that executes an application program that calls the memory acquisition API A core memory area related to the local memory of the core is specified, and memory allocation is executed from the cluster memory area linked to the core memory area. For this reason, for example, when a processor core is divided into several groups (clusters) to increase the management efficiency of a multi-core environment and a memory area is allocated to the cluster, the memory area for the cluster is defined as a cluster memory area Thus, the operating system can dynamically determine the memory allocation from the cluster memory area when the program is executed.

  The invention according to claim 3 or 8 is as described above, and when a virtual global ID is specified and a memory acquisition API is called, a processor that executes an application program that calls the memory acquisition API A memory area related to the local memory of the core is specified, and memory allocation is executed from the global memory area found by recursively tracing the memory area linked to the memory area. For this reason, for example, by making the memory accessible from all the processor cores the global memory area, the operating system can dynamically determine the memory allocation from the global memory area when executing the program.

  The invention according to claim 4 or 9 is as described above, and when a tree structure is created in the memory area and memory allocation from the memory area specified by the heap ID fails, a higher rank of the memory area is determined. Memory allocation is executed from the memory area. For this reason, for example, even when memory resources with high access speed are exhausted, memory allocation can be executed from the next candidate memory area. Therefore, memory allocation can be executed by searching a memory area having the fastest access speed.

  The invention according to claim 5 is as described above, wherein a configuration file describing a relationship between the heap ID and the memory area, a header file for an application program and an operating program are read by reading the configuration file. Information generating means for generating internal data for the system. According to such a configuration, it is possible to change the definition of the memory area and the definition of the heap ID without changing the application program or the operating system simply by rewriting the configuration file and executing the information generation unit. For example, even when a program is ported to a hardware environment with different physical memory or processor cores, it is possible to rewrite the configuration file and execute the information generation means without changing the application program or operating system. Memory allocation can be realized.

It is a figure which shows the structure of the processor and memory which concern on embodiment of this invention. It is a figure which shows the structure of the operating system which concerns on memory management. It is a figure which shows the flow which concerns on a compilation process. It is a figure explaining the format for describing the definition of a memory in a configuration file. It is a figure explaining the format for describing the definition of a memory area in a configuration file. It is a figure explaining the format for describing the definition of heap ID in a configuration file. It is a figure which shows the example of a description of a configuration file. It is a figure which shows the tree structure of a memory area. It is a figure explaining the specification of API for memory acquisition. It is a main flowchart of a memory allocation process. It is a flowchart of a global memory allocation process. It is a flowchart of a cluster memory allocation process. It is a flowchart of a core memory allocation process. It is a flowchart of a real memory allocation process.

  Embodiments of the present invention will be described with reference to the drawings.

  The operating system 10 according to the present embodiment is a program executed in a multi-core environment in which a plurality of processor cores are connected to each other as shown in FIG. The operating system 10 manages hardware resources and provides the application program 40 with various services that abstract the hardware resources. For example, a memory acquisition API that can be called from the application program 40 is implemented, thereby providing a service that allows the application program 40 to safely use memory resources. When this memory acquisition API is called from the application program 40, the operating system 10 executes memory allocation from the physical memory and returns a pointer indicating the start address of the allocated memory to the application program 40. The application program 40 can execute various processes using the memory by referring to the pointer.

  The multi-core processor according to the present embodiment includes a plurality of processor cores. In the present embodiment, as shown in FIG. 1, four processor cores, that is, a first processor core 30a, a second processor core 30b, a third processor core 30c, and a fourth processor core 30d. It has. Each of these four processor cores has its own local memory (such as a primary cache). That is, the local memory 31a of the first processor core, the local memory 31b of the second processor core, the local memory 31c of the third processor core, and the local memory 31d of the fourth processor core exist.

  In the present embodiment, a multi-core processor having four processor cores is described as an example. However, the present invention is not limited to this, and the number of processor cores may be three or less, or five or more. A multi-core environment may be configured by using a plurality of chips each having a plurality of processor cores.

  Further, the execution environment according to the present embodiment includes a shared memory such as an SDRAM in addition to the memory unique to the processor core. These shared memories are allocated to a cluster memory that is assumed to be used by a specific cluster and a global memory 34 that can be accessed from all processor cores. Note that a cluster is obtained by dividing processor cores into several groups, for example, in order to increase the management efficiency of a multi-core environment. In the present embodiment, the first processor core 30a and the second processor core 30b constitute a first cluster 32a, and the third processor core 30c and the fourth processor core 30d constitute a second cluster 32b. Is configured. A cluster memory is assigned to each of these clusters. That is, the first cluster memory 33a and the second cluster memory 33b.

  Although not specifically described in the present embodiment, the cluster structure may be hierarchized. In other words, the clusters may be managed in a tree structure by setting an upper cluster that is a parent of a plurality of clusters.

  In this embodiment, as shown in FIG. 1, the memory having the fastest access speed for a specific processor core is a memory specific to the processor core (for example, the memory having the fastest access speed for the first processor core 30a). Is the local memory 31a of the first processor core). The memory with the next highest access speed (or priority) is the memory of the cluster to which it belongs (for example, the first cluster memory 33a for the first processor core 30a). Further, the memory with the next highest access speed (or priority) is the parent memory of the cluster (for example, the global memory 34 for the first processor core 30a).

  For this reason, depending on which processor core the application program 40 is executed on, an environment in which a memory having a high access speed or a memory to be preferentially allocated changes. For example, when the application program 40 is executed by the first processor core 30a, the memory having the fastest access speed is the local memory 31a of the first processor core. On the other hand, when the application program 40 is executed by the second processor core 30b, the memory having the fastest access speed is the local memory 31b of the second processor core.

  In order to execute appropriate memory allocation under such an environment, the operating system 10 according to the present embodiment includes a memory area creation unit 12 and a memory allocation unit 14, as shown in FIG.

  The memory area creation unit 12 reads internal data 43 (to be described later) when the system is initialized, and creates a plurality of memory areas 20 according to the contents of the internal data 43. The memory area 20 is a unit for the operating system 10 to manage memory resources. The memory area creation unit 12 creates a plurality of memory areas 20 by dividing the memory into addresses and sizes, and creates a tree structure with these memory areas 20 (see FIG. 8). This tree structure will be described in detail later.

  The memory allocation unit 14 refers to a heap ID specified as an argument of the memory acquisition API when the memory acquisition API is called, and executes memory allocation from the memory area 20 associated with the heap ID. is there. The heap ID is defined in a configuration file 41, which will be described later, and can be rewritten by the user. This heap ID will be described in detail later.

  In this embodiment, the memory allocation unit 14 includes a microkernel 16 and a heap manager 15.

  The microkernel 16 is a program for performing program execution control in each processor core, and is executed one by one in each processor core. Therefore, when there are four processor cores as in the present embodiment, four microkernels 16 corresponding to the respective processor cores are executed. Note that when the application program 40 calls the memory acquisition API, an instruction is notified to the microkernel 16 that controls the processor core that is executing the application program 40. The microkernel 16 that has received the instruction specifies the memory area 20 for executing the memory allocation based on the argument (heap ID) of the memory acquisition API, and requests the heap manager 15 that manages the memory area 20 to execute the memory allocation. Perform the assignment.

  The heap manager 15 is a program that controls each memory area 20, and is executed for each memory area 20. For example, as shown in FIG. 8, when seven memory areas 20 exist, seven heap managers 15 corresponding to the respective memory areas 20 are executed. As described above, the heap manager 15 is called by the microkernel 16 when the memory acquisition API is called, and executes memory allocation from the memory area 20 managed by itself. Specifically, when there is a memory allocation request from the microkernel 16, the heap manager 15 secures the memory of the size specified by the microkernel 16 and notifies the microkernel 16 of the address, and the memory It is managed so that it is not used again for memory allocation until it is explicitly released.

  The memory area 20 managed by the heap manager 15 can be roughly classified into three types as shown in FIG. That is, a core memory area, a cluster memory area, and a global memory area 23.

  The core memory area is a memory area 20 related to local memories of a plurality of processor cores, and is created in order to manage these memory areas 20 by the operating system 10. As many core memory areas as the plurality of processor cores are created. In the present embodiment, the first core memory area 21a corresponding to the local memory 31a of the first processor core, the second core memory area 21b corresponding to the local memory 31b of the second processor core, and the third A third core memory area 21c corresponding to the local memory 31c of the processor core and a fourth core memory area 21d corresponding to the local memory 31d of the fourth processor core are created.

  The cluster memory area is a memory area 20 associated with one or more core memory areas, and is created for managing these memory areas 20 by the operating system 10. In this embodiment, the same number of cluster memory areas as the number of clusters are created. That is, a first cluster memory area 22a corresponding to the first cluster memory 33a and a second cluster memory area 22b corresponding to the second cluster memory 33b are created.

  The global memory area 23 is a memory area 20 associated with one or more cluster memory areas, and is created for managing these memory areas 20 by the operating system 10. In the present embodiment, only one global memory area 23 is created. However, a plurality of global memory areas 23 may be provided.

  These core memory area, cluster memory area, and global memory area 23 form a hierarchical structure as shown in FIG. That is, a tree structure is formed in which the core memory area is the lowermost layer, the cluster memory area is the intermediate layer, and the global memory area 23 is the uppermost layer. In the example shown in FIG. 8, the cluster memory area has one hierarchy, but the cluster memory area may form a plurality of hierarchies.

  These memory areas 20 have addresses, sizes, tree structures, and other attributes determined by the description of the configuration file 41 as shown in FIG. Therefore, the setting of the memory area 20 can be changed by rewriting the description of the configuration file 41. For example, the setting can be changed so that the memory area 20 corresponds to the configuration of the physical memory, the number of processor cores, and the like, and can be used for controlling the operating system 10.

  In the configuration file 41, the relationship between the memory area 20 and the heap ID can be freely described and set. Thus, the application program 40 can access the desired memory area 20 using the heap ID.

  The configuration file 41 is read and used by the information generating means 42 as shown in FIG. The information generating means 42 is a configuration tool that can be executed independently (for example, a file in an executable format that can be executed on a computer), reads the contents described in the configuration file 41, and is a header for the application program 40. A file 44 and internal data 43 for the operating system 10 are generated.

  Among these, the internal data 43 is used by the above-described memory area creation unit 12 to read and create the memory area 20 when the system is initialized.

  On the other hand, the header file 44 is used when the source code 45 of the application program 40 is compiled. More specifically, the header file 44 is used when the compiler 46 compiles the source code 45 of the application program 40, thereby generating an object file 47. Since the heap ID is defined in the header file 44, the application program 40 can use the heap ID for calling the memory acquisition API by referring to the header file 44.

(Description example of the configuration file 41)
Next, a description example of the configuration file 41 will be described. FIG. 7 shows a specific description example of the configuration file 41. In the configuration file 41 shown in FIG. 7, three definitions of DEF_MEM (memory definition), DEF_MEMOBJ (memory area 20 definition), and DEF_HEAP (heap ID definition) can be described.

  FIG. 4 shows a format for describing the memory definition (DEF_MEM) in the configuration file 41. By using this format, the memory space can be divided by address and size, and a memory ID (unique character string used in the configuration file 41) can be assigned to the divided memory. Specifically, the memory ID specified by memid is assigned to the memory having the size specified by memsz from the address described in startaddr.

  For example, in the example shown in (1) of FIG. 7, a memory ID of MEM_SDRAM1 is assigned to a memory of 0x8000000 (that is, a memory in a range of 0xc000000 to 0xc7ffffff) with 0xc0000000 as a start address.

FIG. 5 shows the definition (DEF) of the memory area 20 in the configuration file 41.
_MEMOBJ). By using this format, the memory area 20 can be created by specifying the name, position, attribute, parent-child relationship, and relationship with the processor core.

  In the format shown in FIG. 5, “name of the memory area 20 (unique character string used in the configuration file 41)” is specified for memobjid.

  The “attribute of the memory area 20” is specified for membojatr. The specifiable attributes are “MOA_GLLOBAL” meaning the global memory area 23, “MOA_CLUSTER” meaning the cluster memory area, and “MOA_CORE” meaning the core memory area.

  “ownercoreid” specifies “the number of the processor core that manages this memory area 20”. Specifically, when the memory area 20 is a core memory area, it is specified which processor core's local memory the core memory area is associated with. For example, “1” is designated if the core memory area is associated with the local memory 31a of the first processor core (the first core memory area 21a shown in FIG. 8). When the memory area 20 is not a core memory area, the processor core number in which the heap manager 15 that manages the memory area 20 is executed is designated.

  In parentid, “name of the memory area 20 that is the parent of this memory area 20” is designated. Specifically, in the case of the core memory area, the name of the parent cluster memory area is designated. In the case of a cluster memory area, the name of the parent cluster memory area or global memory area 23 is designated. In the case of the global memory area 23, a specified value “MEMOBJ_ROOT” indicating that there is no parent is designated.

  “List of memory IDs belonging to this memory area 20” is specified for memlist. That is, a list of memory IDs defined by the description method described with reference to FIG. 4 is designated.

For example, in the example shown in (2) of FIG. 7, MEM_SDRAM1 (memory in the range of 0xc0000000 to 0xc7ffffff) and MEM_SDRAM2 (0xcc000000).
Global memory area 23 is created with the name “MEMOBJ_GLOBAL1” for memory in a range of ˜0xcfffffff.

In the example shown in (3) of FIG. 7, MEM_CLUSTER1 (0x81200000)
~ 0x8127efff range memory) for "MEMOBJ_CLUSTER1
", A cluster memory area is created. The parent memory area 20 of this cluster memory area is “MEMOBJ_GLOBAL1”.

In the example shown in (4) of FIG. 7, a core memory area is created with the name “MEMOBJ_CORE1” for MEM_CORE1 (memory in the range of 0x8100000 to 0x81007fff). This core memory area uses the local memory of the processor core with the number “1”, and the parent memory area 20 of this core memory area is “MEMOBJ_CLUSTER1”.
Thus, by defining the memory area 20, a tree structure as shown in FIG. 8 is created.

  FIG. 6 shows a format for describing a heap ID definition (DEF_HEAP) in the configuration file 41. By using this format, the relationship between the heap ID and the memory area 20 can be described.

In the format shown in FIG. 6, “heap ID (a unique character string that can be used by the application program 40)” is specified for heapid.
For memobjid, “predetermined virtual attribute” or “name of memory area 20 associated with heap ID” is designated.

  Note that “predetermined virtual attributes” that can be specified in memobjid are “MEMOBJ_GLOBAL” indicating that this heap ID is a virtual global ID, “MEMOBJ_CLUSTER” indicating that this heap ID is a virtual cluster ID, Any one of “MEMOBJ_CORE” indicating that the heap ID is a virtual core ID can be designated.

  For example, in the example shown in (5) of FIG. 7, a virtual global ID is created with a heap ID of “HEAP_GLOBAL”. The virtual global ID is a heap ID for referring to the global memory area 23. When the application program 40 calls the memory acquisition API using the virtual global ID, the operating system 10 searches the usable global memory area 23 and executes memory allocation from the global memory area 23.

  In the example shown in (6) of FIG. 7, a virtual cluster ID is created with a heap ID “HEAP_CLUSTER”. The virtual cluster ID is a heap ID for dynamically allocating a cluster memory area. When the application program 40 calls the memory acquisition API using the virtual cluster ID, the operating system 10 searches for a usable cluster memory area and executes memory allocation from this cluster memory area.

  In the example shown in (7) of FIG. 7, a virtual core ID is created with a heap ID of “HEAP_CORE”. The virtual core ID is a heap ID for dynamically allocating a core memory area. When the application program 40 calls the memory acquisition API using the virtual core ID, the operating system 10 searches for a usable core memory area, and executes memory allocation from the core memory area.

Further, as the “name of the memory area 20 associated with the heap ID” that can be specified for memobjid, the name of the memory area 20 defined by the description method described with reference to FIG. 5 can be specified. When the name of the memory area 20 is directly specified in this way, the heap ID and the memory area 20 are directly associated with each other. When the application program 40 calls the memory acquisition API using such a heap ID, the operating system 10 directly allocates memory from the designated memory area 20. Such a heap ID is called a real memory ID.

  For example, in the example shown in (8) of FIG. 7, a real memory ID is created with a heap ID of “HEAP_CLUSTER1”. This real memory ID is directly associated with the memory area 20 defined by the name “MEMOBJ_CLUSTER1”.

  In the example shown in (9) of FIG. 7, the real memory ID is created with the heap ID “HEAP_CORE1”. This real memory ID is directly associated with the memory area 20 defined by the name “MEMOBJ_CORE4”.

  askparent specifies whether or not to refer to the parent memory area 20 when memory allocation from the specified memory area 20 fails. When “true” is designated, memory allocation is performed by recursively referring to the parent memory area 20 having a tree structure as shown in FIG. For example, when memory allocation from the first core memory area 21a fails, memory allocation from the first cluster memory area 22a is tried. If the memory allocation from the first cluster memory area 22a also fails, the memory allocation from the global memory area 23 is tried. On the other hand, when “false” is specified, memory allocation from the parent memory area 20 is not performed even if memory allocation from the specified memory area 20 fails.

(Memory acquisition API)
Next, specifications of the memory acquisition API will be described. The operating system 10 according to the present embodiment includes a memory acquisition API as shown in FIG. 9, for example, and the memory acquisition API can be called from the application program 40. In this memory acquisition API, “heapid”, “size”, and “addr” can be specified as arguments.

A “heap ID” is designated for the heapid. The operating system 10 tries to allocate memory from the memory area 20 specified by the heap ID specified here. As the heap ID, any one of the virtual global ID, the virtual cluster ID, the virtual core ID, and the real memory ID as described above can be designated. When the application program 40 uses a heap ID, the header file 44 output by the information generation unit 42 is referred to. The header file 44 defines a heap ID that can be used by the application program 40. Note that the heap ID defined in the header file 44 is not limited to the one defined in the configuration file 41, and the information generation means 42 may automatically add it. For example, even if at least one of the virtual global ID, the virtual cluster ID, and the virtual core ID is not defined in the configuration file 41, the information generation unit 42 may automatically output the header file 44. .
In “size”, “size of memory to be acquired” is designated.

  In addr, “pointer to an area for returning the start address of the acquired memory” is designated. When the memory acquisition is successful, the application program 40 can obtain the start address of the acquired memory by referring to the contents of this pointer.

  Note that the return value of this API is an error code. Specifically, “EOK (constant)” is returned when memory acquisition is successful, “EPAR (constant)” is returned when size and addr are invalid, and heap ID is invalid. “ENOEXS (constant)” is returned, and “ENOMEM (constant)” is returned when memory acquisition fails due to memory exhaustion or the like.

(Memory allocation process)
Next, processing of the operating system 10 when the above-described memory acquisition API is called will be described. FIG. 10 is a main flowchart of the memory allocation process.

  First, in step S100 shown in FIG. 10, the application program 40 calls a memory acquisition API, and the microkernel 16 receives a memory acquisition request resulting from the API call. At this time, the microkernel 16 that receives the memory acquisition request is the microkernel 16 that is executed in the processor core in which the application program 40 is executed. The microkernel 16 acquires the heap ID specified by the memory acquisition API, refers to the internal data 43 based on the heap ID, and checks the attribute of the heap ID. Then, the process proceeds to step S101.

  In step S101, it is checked whether the heap ID is a virtual global ID (that is, whether the heap ID is defined with the MEMOBJ_GLOBAL attribute in the configuration file 41). If it is a virtual global ID, the process proceeds to step S102, and a global memory allocation process (see FIG. 11) is executed. On the other hand, if it is not a virtual global ID, the process proceeds to step S103.

  In step S103, it is checked whether the heap ID is a virtual cluster ID (that is, a heap ID defined with the MEMOBJ_CLUSTER attribute in the configuration file 41). If it is a virtual cluster ID, the process proceeds to step S104, and a cluster memory allocation process (see FIG. 12) is executed. On the other hand, if it is not a virtual cluster ID, the process proceeds to step S105.

  In step S105, it is checked whether the heap ID is a virtual core ID (that is, whether the heap ID is defined with the MEMOBJ_CORE attribute added in the configuration file 41). If it is a virtual core ID, the process advances to step S106 to execute a core memory allocation process (see FIG. 13). On the other hand, if it is not a virtual core ID, this heap ID is a real memory ID, so the process proceeds to step S107, and a real memory allocation process (see FIG. 14) is executed.

(Global memory allocation processing)
The global memory allocation process will be described with reference to FIG.
First, in step S200 shown in FIG. 11, the microkernel 16 obtains the number of the processor core from which the memory acquisition API is called (in this embodiment, the number of the processor core in which the microkernel 16 is executed). Then, the process proceeds to step S201.

  In step S201, the microkernel 16 refers to the tree structure of the memory area 20 based on the processor core number acquired in step S200, and acquires the core memory area associated with the number. For example, when the processor core number is “1”, the core memory area (the core memory area defined by the description in (4) of FIG. 7) in which “1” is specified as the ownercore in the configuration file 41 is acquired. Then, the process proceeds to step S202.

  In step S202, it is checked whether the acquired memory area 20 has the “MOA_GLOBAL” attribute, that is, the global memory area 23. If it is the global memory area 23, the memory area 20 is selected as a memory allocation target, and the process proceeds to step S204. On the other hand, if it is not the global memory area 23, the process proceeds to step S203.

  When the process proceeds to step S203, the parent memory area 20 of the acquired memory area 20 is acquired. That is, in the tree structure as shown in FIG. 8, the parent memory area 20 of the currently acquired memory area 20 is acquired. Then, the process returns to step S203 to check whether the newly acquired memory area 20 is the global memory area 23. If it is the global memory area 23, the memory area 20 is selected as a memory allocation target, and the process proceeds to step S204. On the other hand, if it is not the global memory area 23, the process proceeds to step S203 and the same processing as described above is performed. In this way, the parent memory area 20 is recursively acquired until the global memory area 23 is found.

  In step S204, the microkernel 16 calls the heap manager 15 that manages the memory area 20 selected as a memory allocation target, and requests the heap manager 15 to allocate the memory. Then, the process proceeds to step S205.

  In step S205, it is checked whether the memory allocation by the heap manager 15 is successful. If the memory allocation is successful, the process proceeds to step S206. On the other hand, if memory allocation has failed due to exhaustion of memory resources, the process proceeds to step S207.

  When the process proceeds to step S206, the memory pointer of the acquired memory is returned to the application program 40. By using this memory pointer, the application program 40 can use the memory safely. Then, the process ends.

On the other hand, when the process proceeds to step S207, it is checked whether the parent memory area 20 is acquired. When the parent memory area 20 does not exist or when the heap ID specified by the argument of the memory acquisition API is a setting that does not refer to the parent memory area 20 (in the definition of the heap ID in the configuration file 41, askparent is In the case of false), the process proceeds to step S209. In other cases, the tree structure as shown in FIG. 8 is referred to, and the parent memory area 20 of the memory area 20 in which memory allocation has failed is selected as a memory allocation target, and the process proceeds to step S208.
When the process proceeds to step S209, the error code is returned to the application program 40. Then, the process ends.

  On the other hand, when the process proceeds to step S208, the heap manager 15 that manages the parent memory area 20 selected as the memory allocation target is called, and the heap manager 15 is requested to allocate the memory. Then, the process proceeds to step S205 described above, and the already described procedure is repeated. At this time, if memory allocation fails in the parent memory area 20 as well, memory allocation from the parent memory area 20 is recursively attempted.

  As described above, in the global memory allocation process, the memory area 20 (core memory area) related to the local memory of the processor core in which the application program 40 is executed is specified, and the memory area 20 associated with the memory area 20 is specified. The memory allocation is executed from the global memory area 23 found by recursively tracing.

(Cluster memory allocation process)
The cluster memory allocation process will be described with reference to FIG.
First, in step S300 shown in FIG. 12, the microkernel 16 obtains the number of the processor core that called the memory acquisition API (in this embodiment, the number of the processor core in which the microkernel 16 is executed). Then, the process proceeds to step S301.

  In step S301, the microkernel 16 refers to the tree structure of the memory area 20 based on the processor core number acquired in step S300, and acquires the core memory area associated with the number. Then, the process proceeds to step S303.

  In step S303, the parent memory area 20 of the acquired core memory area is selected as a memory allocation target. The parent memory area 20 of this core memory area is a cluster memory area having the “MOA_CLUSTER” attribute. Then, the process proceeds to step S304.

  Note that the processing in steps S304 to S309 is the same as the processing in steps S204 to S209 of the global memory allocation processing described above, and thus description thereof is omitted.

  As described above, in the cluster memory allocation process, the core memory area related to the local memory of the processor core in which the application program 40 is executed is specified, and the memory allocation is executed from the cluster memory area linked to the core memory area. Let

(Core memory allocation processing)
The core memory allocation process will be described with reference to FIG.
First, in step S400 shown in FIG. 13, the microkernel 16 obtains the number of the processor core that called the memory acquisition API (in this embodiment, the number of the processor core in which the microkernel 16 is executed). Then, the process proceeds to step S401.

  In step S401, the microkernel 16 refers to the tree structure of the memory area 20 based on the number of the processor core acquired in step S400, and selects the core memory area 20 associated with the number as a memory allocation target. . Then, the process proceeds to step S402.

  In step S402, the microkernel 16 calls the heap manager 15 that manages the core memory area selected as a memory allocation target, and the heap manager 15 executes the memory allocation. Then, the process proceeds to step S403.

  Note that the processing in steps S403 to S407 is the same as the processing in steps S205 to S209 of the global memory allocation processing described above, and thus the description thereof is omitted.

  As described above, in the cluster memory allocation process, the memory allocation is executed from the core memory area related to the local memory of the processor core in which the application program 40 is executed.

(Real memory allocation processing)
The real memory allocation process will be described with reference to FIG.
First, in step S500 shown in FIG. 14, the microkernel 16 allocates the memory area 20 associated with the heap ID based on the heap ID (real memory ID) specified by the argument of the memory acquisition API. Select as target. For example, when the heap ID “HEAP_CORE4” defined in (9) of FIG. 7 is specified by an argument of the memory acquisition API, the memory area 20 named “MEMOBJ_CORE4” associated with this heap ID is stored in the memory. Select for assignment. Then, the process proceeds to step S501.

  In step S501, the microkernel 16 calls the heap manager 15 that manages the memory area 20 selected as the memory allocation target, and requests the heap manager 15 to allocate the memory. Then, the process proceeds to step S502.

  Note that the processing in steps S502 to S506 is the same as the processing in steps S205 to S209 of the global memory allocation processing described above, and a description thereof will be omitted.

  In this way, in the real memory allocation process, memory allocation is executed from the memory area 20 associated with the designated real memory ID.

(Summary)
As described above, according to the present embodiment, when the real memory ID is specified and the memory acquisition API is called, the memory allocation is executed from the memory area 20 associated with the specified real memory ID. I have to. For this reason, when it is desired to execute memory allocation from a specific memory designated by the application program 40, the memory acquisition API may be called by designating the real memory ID.

  When the virtual core ID is specified and the memory acquisition API is called, the memory allocation is executed from the core memory area related to the local memory of the processor core in which the application program 40 that called the memory acquisition API is executed. I am doing so. For this reason, if the operating system 10 is to dynamically select a memory with high access speed (memory unique to the processor core) and execute memory allocation, the virtual core ID is specified and the memory acquisition API is called. .

  Also, when the virtual cluster ID is specified and the memory acquisition API is called, the core memory area related to the local memory of the processor core in which the application program 40 that called the memory acquisition API is executed is specified, and the core Memory allocation is executed from the cluster memory area linked to the memory area. For this reason, for example, when the processor core is divided into several groups (clusters) in order to increase the management efficiency of the multi-core environment and the memory area 20 is allocated to the cluster, the memory area 20 for the cluster is used as the cluster memory area By defining, the operating system 10 can dynamically determine the memory allocation from the cluster memory area when the program is executed.

  When the virtual global ID is specified and the memory acquisition API is called, the memory area 20 related to the local memory of the processor core in which the application program 40 that called the memory acquisition API is executed is specified, and the memory Memory allocation is executed from the global memory area 23 found by recursively tracing the memory area 20 associated with the area 20. For this reason, for example, by making the memory accessible from all the processor cores the global memory area 23, the operating system 10 can dynamically determine the memory allocation from the global memory area 23 when executing the program. .

  In addition, since a plurality of memory allocation methods as described above are realized by the same memory acquisition API, the memory allocation method can be switched only by changing the definition of the heap ID without changing the application program 40. it can. For example, if the definition of the heap ID is changed by rewriting the configuration file 41 and the heap ID assigned to the virtual core ID is assigned to the real memory ID, the memory acquisition API is used using the heap ID. It is possible to switch the memory allocation method without changing the application program 40 that called. When the virtual core ID is changed to the real memory ID, before the heap ID definition is changed, the memory allocation is executed from the memory area 20 specific to the processor core at the time of program execution, and the heap ID definition is changed. After that, memory allocation from the specific memory area 20 designated by the heap ID is executed.

  Also, a tree structure is created in the memory area 20, and when memory allocation from the memory area 20 specified by the heap ID fails, memory allocation is executed from the upper memory area 20 of the memory area 20. . For this reason, for example, even when memory resources with high access speed are exhausted, memory allocation can be executed from the next candidate memory area 20. Therefore, memory allocation can be executed by searching the memory area 20 having the fastest access speed.

  Also, a configuration file 41 describing the relationship between the heap ID and the memory area 20, and information for reading the configuration file 41 and generating the header file 44 for the application program 40 and the internal data 43 for the operating system 10 Generating means 42. According to such a configuration, the definition of the memory area 20 and the definition of the heap ID can be changed without changing the application program 40 or the operating system 10 simply by rewriting the configuration file 41 and executing the information generation unit 42. can do. For example, even when a program is ported to a hardware environment having a different physical memory or processor core, the application program 40 or the operating system 10 can be changed only by rewriting the configuration file 41 and executing the information generating means 42. And appropriate memory allocation can be realized.

DESCRIPTION OF SYMBOLS 10 Operating system 12 Memory area creation part 14 Memory allocation part 15 Heap manager 16 Microkernel 20 Memory area 21a 1st core memory area 21b 2nd core memory area 21c 3rd core memory area 21d 4th core memory area 22a First cluster memory area 22b Second cluster memory area 23 Global memory area 30a First processor core 30b Second processor core 30c Third processor core 30d Fourth processor core 31a Local memory of the first processor core 31b Local memory of the second processor core 31c Local memory of the third processor core 31d Local memory of the fourth processor core 32a First cluster 32b Second cluster 33a First Raster memory 33b second cluster memory 34 global memory 40 the application programs 41 configuration file 42 information generating means 43 internal data 44 header file 45 source code 46 compiler 47 object file of an application program

Claims (9)

An operating system that is executed in a multi-core environment in which a plurality of processor cores each having a local memory are connected to each other, and that implements a memory acquisition API that can be called from an application program,
A memory area creation unit for creating a plurality of memory areas according to preset internal data;
A memory allocation unit that refers to a heap ID specified as an argument of the memory acquisition API and executes memory allocation from the memory area associated with the heap ID;
With
The memory area includes a core memory area related to a local memory of the plurality of processor cores,
The heap ID includes a real memory ID for directly specifying the memory area and allocating the memory, and a virtual core ID for dynamically selecting the core memory area and allocating the memory,
The definition of the heap ID can be rewritten by the user,
The memory allocation unit
When the real memory ID is specified and the memory acquisition API is called, memory allocation is executed from the memory area associated with the specified real memory ID,
When the virtual core ID is specified and the memory acquisition API is called, memory allocation is executed from the core memory area related to the local memory of the processor core in which the application program that calls the memory acquisition API is executed An operating system characterized by causing The memory area includes a cluster memory area linked to one or more core memory areas,
The heap ID includes a virtual cluster ID for dynamically selecting the cluster memory area and allocating memory,
The memory allocation unit
When the virtual cluster ID is specified and the memory acquisition API is called, the core memory area related to the local memory of the processor core in which the application program that called the memory acquisition API is executed is specified, and 2. The operating system according to claim 1, wherein memory allocation is executed from the cluster memory area linked to the core memory area. The memory area includes a global memory area linked to one or more cluster memory areas,
The heap ID includes a virtual global ID for dynamically selecting the global memory area and allocating memory,
The memory allocation unit
When the virtual global ID is designated and the memory acquisition API is called, the memory area related to the local memory of the processor core in which the application program that called the memory acquisition API is executed is specified, and the memory 3. The operating system according to claim 2, wherein memory allocation is executed from the global memory area found by recursively tracing the memory area associated with the area. The memory area creation unit creates a tree structure in the memory area,
The memory allocation unit
The memory allocation is executed from a memory area higher than the memory area when the memory allocation from the memory area specified by the heap ID fails. Operating system. An operating system according to any one of claims 1 to 4,
A configuration file describing the relationship between the heap ID and the memory area;
Information generating means for reading the configuration file and generating a header file for the application program according to claim 1 and internal data for the operating system;
A compiler that compiles the source code of the application program using the header file;
A programming system comprising: A memory allocation method for executing memory allocation when a memory acquisition API is called from an application program in a multi-core environment in which a plurality of processor cores each having a local memory are connected to each other.
Creating a plurality of memory areas according to preset internal data;
Referring to a heap ID specified as an argument of the memory acquisition API and executing memory allocation from the memory area associated with the heap ID;
With
The memory area includes a core memory area related to a local memory of the plurality of processor cores,
The heap ID includes a real memory ID for directly specifying the memory area and allocating the memory, and a virtual core ID for dynamically selecting the core memory area and allocating the memory,
The definition of the heap ID can be rewritten by the user,
When the real memory ID is specified and the memory acquisition API is called, memory allocation is executed from the memory area associated with the specified real memory ID,
When the virtual core ID is specified and the memory acquisition API is called, memory allocation is executed from the core memory area related to the local memory of the processor core in which the application program that calls the memory acquisition API is executed A method of allocating memory. The memory area includes a cluster memory area linked to one or more core memory areas,
The heap ID includes a virtual cluster ID for dynamically selecting the cluster memory area and allocating memory,
When the virtual cluster ID is specified and the memory acquisition API is called, the core memory area related to the local memory of the processor core in which the application program that called the memory acquisition API is executed is specified, and The memory allocation method according to claim 6, wherein the memory allocation is executed from the cluster memory area linked to the core memory area. The memory area includes a global memory area linked to one or more cluster memory areas,
The heap ID includes a virtual global ID for dynamically selecting the global memory area and allocating memory,
When the virtual global ID is designated and the memory acquisition API is called, the memory area related to the local memory of the processor core in which the application program that called the memory acquisition API is executed is specified, and the memory 8. The memory allocation method according to claim 7, wherein memory allocation is executed from the global memory area found by recursively tracing the memory area associated with the area. Create a tree structure in the memory area,
9. The memory allocation according to claim 6, wherein when memory allocation from the memory area specified by the heap ID fails, memory allocation is executed from a memory area higher than the memory area. Memory allocation method.

Images