JP2006185456A - Memory allocation device, memory allocation method and program recording medium - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To eliminate the compaction and to increase the use efficiency of a memory. <P>SOLUTION: This memory allocation device is provided with a characteristic detection means for detecting characteristics of an object generated in a heap area of the memory and an allocation determination means for determining allocation of the object to the heap area according to the characteristics detected by the characteristic detection means. Thus, allocation of the object to the heap area according to size and lifetime of the object, etc. and the user efficiency of the memory is improved. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a computer memory allocation device, a memory allocation method, and a program recording medium.

  First, definitions of various terms used in the specification of the present invention are shown below. The source symbols are as follows.

JIS: JIS Industrial Glossary Dictionary 4th Edition (published by Japanese Standards Association)
Reference 1: Information Technology Glossary (Ohm)
Reference 2: Encyclopedia of information processing terms (Ohm Publishing)
Reference 3: Advanced Software Glossary (Ohm)
Reference A: SUPER ASCII Glossary Help on Internet

(1) Process:
General terms that mean processes and processes (Ref. 2)
(2) Thread:
An execution unit or control flow that is a target of a processor schedule when a process that can be executed in parallel in a single execution environment called a process or task is divided into a plurality of processes. (Reference 3)
(3) Context:
An object that stores the information needed to execute a method (in connection with an object-oriented system). The context consists of the context of the call destination, the method object containing the program, the program counter, the information of the stack pointer, the place to take arguments and temporary variables, and the evaluation stack. Although such an execution environment is taken as an object, it is called a heap language because it is a feature of a high-level language that supports processes and the like. On the other hand, in the case of PASCAL and ALGOL 60, the execution environment is taken in a stack, and in FORTRAN, it is taken in a fixed area. (Reference 1)
(4) task:
One or more sequences of instructions (JIS) that are handled by a control program as an element of work to be performed by a computer in a multiprogramming or multiprocessing environment
(5) Garbage:
An object that has not been referenced anywhere but has been created. Garbage is collected at the garbage collector. (Reference 1)
(6) Garbage Collection:
A program that is central to memory management (in relation to object-oriented systems). When the main memory is used up, the main calculation is stopped and the garbage collector is moved to collect all objects that are no longer used. If the garbage collector works in this way, the calculation stops and the input / output does not respond at all, and it cannot be used for applications that require real-time response. (Reference 1)
(7) Interpreter:
Translation program (JIS) that performs interpretation
(8) Real time:
Term related to processing of data performed by a computer in accordance with time requirements determined by external processing while having a relationship with other processing outside the computer. Real time. (JIS)
(9) Object:
An entity that combines a procedure (defined procedure) with the characteristics of the data, which performs calculations and stores the local state. (Reference 1)
(10) Class:
A collection of objects with the same set of procedures and data structures. (Reference 3)
(11) Heap area:
A work area that is used as needed during program execution. (Reference 2)
(12) Scheduling:
Selecting a job or task to be dispatched. (JIS)
(13) Event:
The hardware / software notifies other hardware / software of changes in its own state. In general, in this notification, various parameters representing the type of event and the state of hardware / software are collected as a message and transmitted to the other party. The side receiving the event notification performs appropriate processing based on the message parameters. (Reference A)
(14) Event flag:
An inter-task synchronous communication mechanism comprising a function for a task to wait for the occurrence of one or more events and a function for notifying the event. (Reference 3)
(15) Semaphore:
A system that processes multiple processes and tasks in parallel, and performs synchronization, message control, and interrupt processing between processes and tasks. (Reference 3)
(16) Virtual machine (virtual mathine):
An environment for executing application programs that are incorporated in a plurality of specific platforms (OS and hardware) and do not depend on a specific platform. As long as the same virtual machine is provided, the same application program can be executed even if the platform changes.

(17) Java VM (Java Virtual Machine) (Java is a trademark of Sun Microsystems):
An environment for executing a Java application program (Java is a trademark of Sun Microsystems) incorporated in an operating system. A general program takes the style of compiling source code and generating executable code optimized for each operating system. A program written in Java (Java is a trademark of Sun Microsystems) is also created in the same procedure, but the compiled code takes the form of intermediate code that does not depend on a specific operating system. It is the role of the Java virtual machine (Java is a trademark of Sun Microsystems, Inc.) that loads it and executes it while converting it into code suitable for each operating system. If the same virtual machine is provided, the platform will change. However, the same code can be executed.

(18) Free area:
Available and unused area on the heap area.

(19) Normal thread:
A thread that performs processing that does not require real-time performance.

(20) Mark table:
A table that has a one-to-one correspondence with objects that exist to check whether an object is not referenced from anywhere. When it is confirmed that a certain object has a reference, the table column corresponding to the object is marked. When all the reference relationships are examined, the object without the mark is unnecessary and can be removed.

(21) Life time of the object:
The time until an object is created and deleted.

(22) Write barrier:
Check for changes in the reference relationship to an object, and do some processing when rewriting occurs. In this case, when rewriting occurs, a mark is placed in the mark table column corresponding to the object to which the reference to be rewritten points.

(23) sweeping:
Processing to remove unnecessary objects on the heap area.

(24) Create the object:
Create a new object. Specifically, allocate a part of the heap area to the object and initialize the contents.

(25) Delete the object:
Remove unnecessary objects. Specifically, release the area secured in the heap area.

(26) Reference:
Information that identifies an object B in order for one object A to access another specific object B. Specifically, a pointer or index pointing to the object B.

(27) Change the reference (change the reference / reconnect the reference):
Changing the reference from the current object B to another object C.

  In a conventional single processor computer system, when a plurality of threads are processed in parallel on an operating system, a semaphore is conventionally used for exclusive control using a shared memory and for synchronization between a plurality of tasks. Exclusive control is performed using event flags and the like.

  In addition, so-called dynamic storage management, which dynamically allocates memory in a single address space at the time of program execution without performing virtual storage, for example, for the purpose of operating a program in a small amount of memory environment, has been conventionally performed. Has been done. According to such dynamic storage management, unless the memory area is explicitly released by the program, a memory area that is no longer used in the program execution process is generated. As a result, the free area that the program can use gradually becomes insufficient. In order to avoid these problems, a memory area (garbage) that is no longer used is extracted and collected (collected) to make it a free area that can be used again automatically. I have to.

  FIG. 54 is a flowchart showing a conventional garbage collection processing procedure. Various methods such as a mark & sweep method, a copying method, and a reference counting method are considered as the garbage collection algorithm. Here, the mark & sweep method is exemplified. As shown in FIG. 54, first, interrupts are prohibited so that no thread other than the garbage collection thread is executed during the garbage collection, and the single thread mode is set (s201). Subsequently, the mark storage areas (hereinafter referred to as “mark tables”) respectively corresponding to the objects allocated to the garbage collection target areas (hereinafter referred to as “heap areas”) are cleared (s202). . Subsequently, an object referenced from any object is detected based on information indicating the reference relationship of the objects allocated in the heap area, and a mark processing is performed on a mark table corresponding to the detected object. (s203). By this process, an object that is not referenced by any object is an object that is no longer used, and a mark table corresponding to the object is not marked. Therefore, the unmarked object is extracted as a new object assignable area, that is, a free area (s204). For example, this free area is generated as list structure data. Thereafter, the interrupt prohibition is canceled and the multi-thread mode is restored (s205).

  Conventionally, such garbage collection is automatically started when the free area of the memory is reduced to a predetermined amount.

  Further, when garbage collection is performed, an object having an arbitrary size (memory size) is arbitrarily released, so that a fragment is generated. In view of this, memory compaction (hereinafter simply referred to as “compaction”) in which the object allocation areas are sequentially packed from the top, for example, is performed so that a continuous large area can be obtained.

  Here, the literature discovered when conducting the prior art search is shown.

(1) Incremental Garbage Collection of Concurrent Objects for Real-Time Application
This paper calculates the ratio of the required GC processing time from the total processing time for the 1978 real-time GC written by Baker.

(2) Distributed Garbage Collection for the Parallel Inference Machine: PIE64
This is a method of improving the real-time property by shortening the individual processing time by finely dividing the area where GC is performed, and does not cover all areas. Further, scheduling is not described.

(3) Garbage Collection in Distributed Enviroment
An evolution of Baker's idea adapted to a distributed network environment. It tries to solve network specific problems.

(4) When a system call is issued, the priority of a task activated by the system call is controlled.

(5) Japanese Patent Application Laid-Open No. Hei 3-231333 It is once shown that the size of an object is detected and a work area is secured in a memory according to the size.

(6) IEICE Vol.80 No.6 pp586-592
The concept of multimedia operating system is shown.

(7) Japan Software Science Society 12th D7-4
It is shown that the size of the object is written at the top of the object on the stack.

(8) 11TH Real-Time System Symposium "Incremental Garbage Collection of Concurrent Object for Real-Time Applications"
The idea of a reference tree between objects is shown.

(9) Information Processing Society of Japan 38th National Convention 5U-7
It has been shown that memory allocation is made in relation to the lifetime of the object.

(10) Lecture Notes in Computer Science 259 "Garbage Collection in a Distributed Environment"
The technical idea about controlling the GC according to the call of the application program interface and the object reference is shown.

  In a conventional system that implements the exclusive control function described above by using computer resources such as semaphores and event flags, when the resource is used by another thread, the other thread You have to wait for the resources to be released. When such a resource waiting time occurs, it becomes a major obstacle in a system that requires real-time performance. In other words, a thread in a resource waiting state cannot process until the resource is released and cannot respond in real time.

  For example, according to the conventional garbage collection (hereinafter referred to as “GC”) method, the larger the memory space, the longer it takes to find an area that may be collected as garbage. For example, in a heap area of 64 to 128 MB Since several seconds are required and GC is performed irregularly when the free area decreases to some extent, it cannot be used in a system that requires real-time performance.

  In a system that requires real-time performance, if some event (interrupt) occurs during execution of a certain task, other threads corresponding to the event will be processed. For example, the worst value is required to be several tens of μsec or less. However, as described above, when the GC is activated cannot be predicted, and once activated, the CPU is devoted to the GC for several seconds, and real-time processing is impossible during that time.

  The above problem is not limited to the case of GC, but is a problem common to systems in which a long resource waiting state occurs.

  Information processing Vol. 35 No. 11 pp1008 to pp1010 shows a method of ensuring the real-time property by performing the conventional copying method incrementally as another method of GC. According to this method, since interruption can be permitted in the middle of GC, it is possible to perform parallel processing with other threads in a time division manner. However, in the method of performing the copying method incrementally, other threads cannot use the memory during copying, so only a very small part of threads that do not use the memory can perform parallel processing. Also, the copying method requires that the memory areas of the copy source and the copy destination be secured, so that the memory use efficiency is low and it is not suitable for a system that operates in a small memory environment.

  In addition, a method of assigning a mark every time the reference relationship is changed in order to cope with multi-threading by the mark & sweep method is called “On-the-fly GC”. A method for implementing a CPU is shown in Information Processing Vol.35 No.11 pp1006 to pp1008. However, with this method, if the object is always created and the reference relationship has changed, you must go through the already marked tree many times to find and mark the new node, The work may not end indefinitely, or it takes a very long time. This method also required the system to be locked during the sweep.

  Then, when performing compaction in order to eliminate a fragment caused by GC such as the conventional mark and sweep method, a large amount of CPU power is required. In addition, if this compaction is not performed, there is a problem that the memory use efficiency is lowered.

  An object of the present invention is to eliminate the need for compaction and to improve the use efficiency of a memory.

  Furthermore, in the conventional object-oriented system, the long-lived object that exists permanently and the short-lived object that disappears in a short time are mixed in the heap area. As a result, a fragment is surely generated, and the memory use efficiency is suddenly lowered. In addition, when GC is performed, it is necessary to determine whether or not an object that is permanently present is garbage, and this is a waste of CPU power. In contrast, a so-called generational garbage collection method that considers an object that has existed for a certain period of time as being permanently present and removes that object from the existence survey has been conventionally considered. However, there were drawbacks that unnecessary objects persisted or that each object had to be examined for a certain period of time.

  Another object of the present invention is to reduce fragmentation in consideration of the lifetime of each object, to improve memory use efficiency, and to reduce waste of CPU power.

  The present invention has the following configuration in order to solve the above problems.

(1) characteristic detection means for detecting characteristics of an object generated in the heap area of the memory;
Allocation determining means for determining allocation of the object to the heap area according to the characteristics detected by the characteristic detecting means;

  In this configuration, the characteristic detection unit detects the characteristic of the object generated in the heap area of the memory, for example, the size of the object and the life of the object, and the allocation determination unit detects the characteristic of the heap area according to the detected characteristic. Determine the assignment of the object. Therefore, the allocation of the object to the heap area can be determined according to the object characteristics, so that the memory usage efficiency can be improved.

(2) The characteristic detection means is means for detecting a distribution of the size of an object allocated in the heap area,
The allocation determining means includes an allocation size determining means for determining an integer multiple of a fixed size larger than the center of the distribution as an allocation size of a new object for the heap area.

  In this configuration, the size distribution of the object is detected as the characteristic of the object. In general, in an object-oriented system, an occurrence frequency distribution of the size of an object (size on a memory) generated when a program is executed shows a normal distribution. On the other hand, when a new object is generated, an allocatable area is extracted from a free area on the memory. As described above, a size larger than the center of the object size distribution is set as a new object allocation size. When a new object is allocated after the allocated object is deleted, an object smaller than the allocated size can be reused. Since the allocation size is larger than the distribution center of the normal distribution, a memory area in which many objects have been used can be reused. This also improves the memory usage efficiency without performing compaction. In addition, CPU power for compaction is not required, and a highly responsive system can be configured with a small CPU.

  (3) The characteristic detection means is a program module that is incorporated into the system at the start of use of the system, and is separated from the system after detecting the size distribution of the object.

  In this configuration, once the object size distribution is detected and after the object allocation size is determined, the memory area and CPU power are not wasted.

  (4) The allocation size determining means is a program module that is incorporated in the system at the start of use of the system and is disconnected from the system after the fixed size is determined.

  In this configuration, once the object size distribution is detected and after the object allocation size is determined, the memory area and CPU power are not wasted.

(5) heap area dividing means for dividing the heap area into a plurality of sizes in advance;
Means is provided for allocating an area having a size smaller than the size of the object when the object is generated.

  In this configuration, many objects can reuse the heap area of the memory without waste, and the use efficiency of the memory is improved without performing compaction. In addition, CPU power for compaction is not required, and a highly responsive system can be configured with a small CPU.

  (6) The heap area dividing unit is a unit that divides the heap area by calling an application program interface having the number of divisions of the plurality of sizes and each size as an argument.

  In this configuration, many objects can reuse the heap area of the memory without waste, and the use efficiency of the memory is improved without performing compaction. In addition, CPU power for compaction is not required, and a highly responsive system can be configured with a small CPU.

  (7) Means for setting the fixed size by calling an application program interface is provided.

  With this configuration, another device, system, and algorithm can measure the size distribution of objects allocated within the heap area of memory and register a fixed size that is the basis for the determined object allocation size. CPU power and memory usage efficiency can be improved.

(8) storing data corresponding to the time when the object is generated from the class, and detecting the life of the object when deleting the object, and providing means for providing the data of the life to the class,
The characteristic detection means is means for detecting the lifetime of an object generated from a class,
The allocation determination means is a means for determining an object generation area for the heap area to be allocated to the object based on the life of the object detected by the characteristic detection means.

  In general, in an object-oriented system, an object is generated using a class as a template. Therefore, objects generated from the same class have substantially the same lifetime. Therefore, the data corresponding to the time when the object is generated from a certain class is stored, and when the object is deleted, the lifetime of the object is detected, and this is used as the lifetime data of the class that generated the object. When storing and generating an object from the class, a long-life object and a short-life object are generated in different areas by generating objects in different heap areas based on the lifetime data. As a result, fragments in the long-life region are greatly reduced, and the memory usage efficiency is improved. In addition, when performing GC, the CPU power consumed by the GC can be reduced by intensively processing the region where the short-lived object is generated.

  According to the present invention, a memory area in which many objects have been used can be reused, and this improves the memory use efficiency without performing compaction. In addition, CPU power for compaction is not required, and a highly responsive system can be configured with a small CPU.

  In addition, by generating objects in different heap areas based on lifetime data, long-lived objects and short-lived objects are generated in different areas, so fragments in the long-lived area are greatly reduced. , Memory usage efficiency is improved. In addition, when GC is performed, the CPU power consumed by the GC can be reduced by intensively processing the area where the short-lived object is generated.

  Hereinafter, a program control apparatus according to an embodiment of the present invention will be sequentially described with reference to FIGS.

  FIG. 1 is a block diagram showing the hardware configuration of the apparatus. The apparatus basically comprises a CPU 1, a heap area for generating an object group, a memory 2 for storing a mark table and the like, and an I / O 3 for input / output from / to the outside. When a necessary program is loaded from the outside into the memory, the CD-ROM reading interface 4 is used to read the CD-ROM 5 on which the program has been written in advance. This CD-ROM corresponds to a program recording medium according to the present invention.

  FIG. 2 is a block diagram showing a software configuration. In the figure, the kernel part manages CPU and memory as resources and realizes a multi-thread function by time division. The VM (virtual machine) portion is software that interfaces the program and the kernel. Here, the entire hierarchy below the VM as seen from the application program acts as, for example, a Java virtual machine (Java is a trademark of Sun Microsystems). In this case, the kernel and the VM portion constitute Java OS (Java is a trademark of Sun Microsystems). The VM includes an interpreter that interprets a program when given as an intermediate code such as a byte code, and a program module that is called according to the interpretation. The programs in the figure are various threads based on intermediate codes, and execute internal program modules via the interpreter.

  FIG. 3 is a diagram showing the reference relationship of objects generated in the heap area of the memory and the relationship with the stack. When an object is generated for the heap area, a reference relationship from one object to another object forms a tree structure extending from the root node as shown in FIG. For example, if a global variable is declared, an object corresponding to the variable is generated. In addition, a stack for storing information such as argument area, return address, local variable, work area, etc. is generated for each thread. For example, a reference relationship from a local variable on the stack to a global variable on the tree as shown by an arrow in the figure. Etc. are also memorized. These stacks are stored in a predetermined area outside the heap area.

  FIG. 4 is a detailed block diagram showing the configuration of the software shown in FIG. In the figure, a GC module 10 is a program module for various processes for performing GC, and a GC thread 11 executes GC by calling these modules. Further, in this example, the interpreter 12 calls the “object generation” of the GC module 10 when there is an object generation request from the “thread 4”, and when there is a request to change the reference relation between objects, the GC module 10 10 “Mark assignment” is called.

  In the example shown in FIG. 4, each thread is represented by an intermediate code (for example, a byte code in the case of a Java applet (Java is a trademark of Sun Microsystems)), but the intermediate code is converted into a native code for the VM. A compiler may be provided. (For example, in the case of Java (Java is a trademark of Sun Microsystems), JIT (Just-In-Time Compiler) is provided.) In this case, the interpreter 12 shown in FIG. The GC module 10 is directly accessed without intervention.

  FIG. 5 is a diagram showing an example in which compaction is performed to eliminate fragments generated in the heap area by performing GC. In the figure, the hatched portion is an object, and by compacting this, fragments are eliminated as shown in (B), and a continuous memory space is expanded.

  The compaction is performed by the “compaction” program of the GC module shown in FIG.

  FIG. 6 is a diagram illustrating an example of using an API for detecting whether or not a context switch has occurred. As shown in FIG. 5A, before executing the process 1, the process 1 is executed after issuing an API #A requesting the start of detecting whether or not a context switch has occurred. After the end of process 1, API #B is issued to request the end of the context switch occurrence detection. In the example shown in (A), since no context switch has occurred during this time, the next processing 2 is performed as it is. If the process of thread # 2 is performed in the middle of process 1, as shown in (B), that is, if a context switch has occurred, process 1 is discarded after issuing API #B. For example, in the process of copying the contents of the area A of the memory to the area B, if a context switch occurs during the copying process, the contents of the area A may change and the contents of the areas A and B may not match. If they do not match, the copy is not made, so the area B is invalidated. This is the same as the case where the process was not performed from the beginning, and it is nothing other than discarding the process itself.

  FIG. 7 shows the above processing as a flowchart. First, after issuing API #A, processing 1 is executed (s1 → s2). After this processing 1 is completed, API # B is issued to obtain the return value (s3). If the return value indicates the occurrence of a context switch, the process 1 is discarded and the process 1 is executed again (s4 → s5 → s1 → s2). If the return value represents the absence of a context switch, the process ends. In this way, it is possible to know whether or not a context switch has occurred within a predetermined period, so if a context switch occurs, the processing during that time is discarded and invalidated, even though the system is not actually locked. Exclusive control can be performed.

  FIG. 8 is a flowchart showing a processing procedure in the kernel of API #A and API #B. If API # A is issued (system call), the flag indicating whether or not a context switch has occurred is cleared. When API # B is issued, the flag state is returned to the thread as a return value.

  FIG. 9 is a flowchart showing the processing procedure of the context switch. When context switching is performed by the scheduler, the above-described flag is set and then context switching is executed. That is, the execution state of the thread before the switch is stored as a context, and the context of the thread after the switch is read and set in a CPU register or the like.

  FIG. 10 is a flowchart showing a processing procedure of the compaction. First, the head object in the heap area is specified (s11), an area for copying the object to the head of the heap area is secured (s12), and some data is written to the area by another thread during copying. Then, the API # A is issued (s13). Then, as shown in FIG. 5, the objects in the heap area are sequentially packed from the top to the empty area (s14). When copying for one object is completed, the API #B is issued (s15). As a result, whether or not a context switch has occurred during a period from when API #A is issued until API #B is issued is obtained as a return value of API #B. If a context switch has occurred, the object copied this time is copied again to the area already secured (s16 → s13 →...). If no context switch has occurred, the same processing is performed for the next object (s16 → s17 → s18 →...). Thus, compaction can be performed simultaneously with other threads without locking the system.

  In the above-described example, the present invention is applied to compaction in GC by the mark & sweep method. However, in the case of application to GC by the copying method, the processing shown in FIGS.

  FIG. 11 is a flowchart of GC according to the above copying method. First, the pointer is moved to the root node of the tree-structured data representing the object reference relationship (s21), and the object in the From area corresponding to the root node is copied to the To area (s22). (The heap area is divided into a From area and a To area, and only objects that are not garbage in the To area are reconstructed by copying only the objects that should remain in the From area to the To area. It is garbage collection by the copying method that alternately repeats the operation using the To area as the From area and the To area as the From area.) Thereafter, the pointer is moved to the next object in the reference relationship by tracing the tree (s23). The object is copied to the To area (s24). This process is performed for all objects that can be traced in the tree.

  FIG. 12 is a flowchart showing the contents of the copying process in FIG. First, an area for copying an object to be copied to a predetermined position in the To area is secured, and no data is written to the area by another thread during copying, and the above API # A is issued. From (s31), the object is copied from the From area to the To area (s32). Thereafter, the API # B is issued (s33). As a result, whether or not a context switch has occurred during a period from when API #A is issued until API #B is issued is obtained as a return value of API #B. If a context switch has occurred, the object copied this time is copied again to the area already secured (s34 → s31 →...).

  FIG. 13 and FIG. 14 do not detect the presence / absence of a context switch and ensure the exclusivity, but the processing procedure when the exclusivity is ensured by detecting whether or not the object to be copied has been rewritten before copying. It is a flowchart which shows.

  When copying, first, an area for copying an object to be copied to a predetermined position in the To area is secured, and some data is not written in the area by another thread during copying, and then FIG. As shown, API # C is issued (s41). This API is an application program interface that requests detection of whether or not writing to a specified memory area has occurred. Subsequently, the object is copied from the From area to the To area (s42). Thereafter, API # D is issued (s43). This API is an application program interface that returns as a return value whether or not any data has been written to a specified memory area between the time API # C is called and the time API # D is called. Therefore, by designating the memory area of the object to be copied and issuing API # C and looking at the return value of API # D, it can be determined whether or not the object has been referenced. If the object is referenced, there is a possibility that the contents have been rewritten, so the object is copied again (s44 → s41 →...).

  FIG. 14 is a flowchart showing a processing procedure in the kernel of API # C and API # D. If API # C is issued (system call), clear the specified work area and set the MMU (Memory Management Unit) so that an exception occurs when the area specified by the API # C parameter is written. Set. When API # D is issued, the above setting for the MMU is canceled so that no exception occurs when the area specified by the above parameter is written. The state of the flag set in the work area is returned to the thread as a return value.

  FIG. 15 is a flowchart showing the processing contents of the MMU when the exception occurs. When an exception occurs, the reference flag in the work area is set.

  In the above example, the case of GC by the copying method is shown, but the present invention can be similarly applied to the case of compaction by the mark & sweep method.

  Next, a case will be described in which the priority of GC threads that can be incrementally collected is automatically switched. FIGS. 16 and 17 are diagrams showing an example in which the priority of GC threads that can be incrementally collected is automatically switched.

  As shown in FIG. 16A, operations of increasing the priority of the GC thread in a high priority time (for example, the highest priority) and lowering the low priority time (for example, the lowest priority) are alternately performed. .

  (B) of the figure shows an example in which a thread having a medium priority other than the GC thread is simultaneously performed. That is, when the priority of the GC thread is low, if a thread with a higher priority is in the Ready state, the context is switched. If the priority of the GC thread becomes high during execution of the thread, the context is assigned to the GC thread. Is switched and processing of the GC thread is interrupted, processing of threads other than the above-described GC thread is performed. In this way, since the GC thread is always executed at a constant period, it is possible to prevent the free area from being chronically insufficient, and to always maintain high performance.

  FIG. 17 is a flowchart showing a processing procedure performed by the kernel regarding switching of thread priorities. There are a plurality of priority values, and the values can be set by issuing corresponding APIs. Here, when setting two priorities of the GC thread, if an API for setting a high priority value is issued, as shown in FIG. Set as the value of. Similarly, when an API for setting a low priority value is issued, the value is set as the low priority value of the GC thread, as shown in (B). When an API for setting a high priority time of a GC thread is issued, as shown in (C) of the figure, an API for setting the value and similarly setting a low priority time is issued. Then, the value is set as shown in FIG.

  FIG. 17E is a flowchart showing the processing procedure for the kernel scheduler. Here, in the initial state, it is assumed that the GC thread is queued for resource allocation in the high priority queue. First, the data (data for identifying the GC thread) is transferred to the high priority queue. Remove from the queue and insert into the low priority queue (s51). Then, the scheduler waits for the preset low priority time (s52), and then extracts data for identifying the GC thread from the low priority queue and inserts it into the high priority queue (s53). . Then, the scheduler waits for the set high priority time (s54). By repeating the above processing, the priority of the GC thread is alternately switched as shown in FIG. 16A by the operation of the scheduler. For threads other than the GC thread, scheduling similar to the prior art is performed according to the queue of the queue corresponding to the priority of the thread, and context switching is performed as shown in FIG.

  FIG. 18 shows a case where the high priority time of the GC thread can be set by the API. FIG. 19 is a flowchart showing a processing procedure in the kernel in response to the API call. If this API is issued (system call), the above high priority time is set (registered) by the API parameter.

FIG. 20 is a flowchart showing an example of a program that uses an API that allows the high priority time of the GC thread to be set. First, the state of the flag shown in the first loop is checked (s61). Since it is initially in an OFF state, this flag is turned on (s62), the current free area is checked, and it is recorded (s63). Initially, the GC high priority time and low priority time are predetermined default values. After stopping for a certain time by the scheduler (s64), this time, the size of the free area capacity examined last time is compared with the current free area capacity (s65), and if the free area capacity has increased, The high priority time of the GC thread is shortened (s66 → s67), and if the free area capacity is reduced, the high priority time of the GC thread is lengthened (s68). The above processing is repeated.
As a result, the priority of GC is automatically adjusted automatically.

  FIG. 21 shows a case where a cycle based on the high priority time and the low priority time of the GC thread can be set. (A) is when the period is long, and (B) is when the period is short.

  FIG. 22 is a flowchart showing a processing procedure in the kernel in response to a call to the period setting API that allows the period to be set. If this period setting API is issued, the values of the currently set high priority time and low priority time are read, and the ratio (ratio) is calculated (s71 → s72 → s73). Thereafter, the high / low priority times are recalculated according to the value of the period specified by the parameter of the period setting API (s74). Then, the high priority time and the low priority time are set and updated (s75 → s76).

  For example, in the case of an application program that requires continuous CPU resources, such as processing a continuous pulse, issue a cycle setting API so that the cycle of the GC thread is shortened, and it will be interrupted like a normal application program In an application program that uses CPU resources, a cycle setting API is issued so that the cycle becomes longer.

  Next, a case where a GC thread is executed at a necessary time and real-time performance is ensured will be described.

FIG. 23 and FIG. 24 are examples in which the GC thread is executed at a necessary time and the real-time property is ensured. In the example shown in FIG. 23, the thread 1 and the thread 3 are threads that require real-time property. The thread 2 is a thread that does not require real-time property (normal thread). The thread 3 is a GC thread. If event 1 occurs when thread 2 is being executed in a normal state where there are many free areas in the memory, the process is transferred to thread 1, and if the process of thread 1 resulting from the process of event 1 is completed, thread 2 Return to. Similarly, if event 2 occurs, the process moves to thread 3. If the free area is lowered to a predetermined warning level by the processing of the thread 2, the processing of the thread 2 is interrupted and the GC thread of the thread 3 is executed. When a free area is secured by this process, the process returns to the thread 2 process. If event 1 occurs during the processing of the GC thread, the processing moves to thread 1 even during the GC. In such a thread that requires real-time properties, the amount of objects that are generated is generally small and can be roughly predicted. Therefore, if the warning level is set accordingly, the thread 2 can perform processing, It is possible to avoid the disadvantage that the free area is greatly reduced and the processing requiring the real time property of the thread 1 and the thread 3 cannot be executed.

  FIG. 24 is a flowchart showing the processing procedure of the scheduler that performs the context switch processing. First, whether or not an event has occurred is detected (s81). If an event has occurred, the context is switched to the corresponding real-time thread (s82). If no event has occurred and the free area is greater than the warning level, the context is switched to the normal thread with the highest priority (thread 2 in the example shown in FIG. 23) (s83 → s84). If the free area is less than the warning level, the context is switched to the GC thread (s85).

  Next, an example of a forced context switch in the API that requests detection of a context switch will be described. FIG. 25 shows an example of a forced context switch in the API that requests detection of a context switch. In the example shown above, it is possible to determine whether or not a context switch has occurred between the issuance of API #A and the issuance of API #B. In the example, when the priority of GC is switched between high and low alternately, it is predicted that a context switch will occur while issuing the API for exclusive control described above, so that unnecessary processing is not performed. It is a thing. That is, when API #A ′ is issued while the high priority GC thread is being executed, API #A ′ determines whether or not necessary processing is completed before the high priority time ends. If it is not completed, the priority of the GC thread is lowered at that time. In the example shown in FIG. 25, since the priority of the GC thread is lowered, the context is switched to a medium priority thread other than the GC thread. This avoids wasteful processing.

  FIG. 26 is a flowchart showing a processing procedure in the kernel in response to the API #A 'call. If this API is called, the context switch flag is cleared (s91), and the remaining time of the high priority time of the GC thread is acquired (s92). Then, the exclusive time (time from issuing API # A 'to issuing API # B), which is a parameter of API # A', is compared with the remaining time (s93). If the remaining time is shorter than the exclusion time, the priority of the GC thread is forcibly lowered (s94). Note that the processing content by the API #B call and the processing content of the context switch are the same as those shown in FIGS.

  Next, an example of switching the GC algorithm according to the memory (heap area) usage will be described. FIG. 27 is a flowchart showing a processing procedure for switching the GC algorithm according to the memory (heap area) usage. First, a memory usage value and a threshold value indicating which algorithm is used for GC are set (s101), and the memory usage is acquired (s102). This is the total memory size of the objects generated in the heap area. When the memory usage exceeds the threshold th1, GC is performed according to the procedure of the GC algorithm (1) (s103 → s104). If the memory usage exceeds the threshold th2, GC is performed according to the procedure of the GC algorithm (2) (s105 → s106). The same applies hereinafter. Here, the threshold value th1 is smaller than the threshold value th2, and the GC algorithm (1) performs the process of alternately repeating the priority of the GC thread shown in FIG. As the GC algorithm performed when the threshold is high, the irregular GC shown in FIG. 23 is executed. Here, the GC itself is performed by, for example, a mark & sweep method. Normally, in the former case, the CPU load is light and GC is performed exclusively by this method. However, when a large amount of memory is used in a short time by a normal thread, the GC is emphasized by the method shown in FIG. To do. In this way, a wide free area is always secured and real-time performance is maintained.

  Next, an example of determining a new object allocation size for the heap area at the time of object generation will be described. 28 to 30 are diagrams relating to processing for determining a new object allocation size for the heap area at the time of object generation. In general, the distribution of the size of an object generated by executing a program shows a substantially normal distribution as shown in FIG. Its central value is within the range of 32 and 64 bytes. Therefore, as shown in FIG. 29A, a size larger than this central value and an integer multiple of the power-of-two bytes is set as the object allocation size. Conventionally, as shown in FIG. 5B, since the object is arbitrarily assigned in an amount corresponding to the size of the object to be generated, fragments of irregular sizes are generated when the object is deleted. According to the present invention, since the size of the newly generated object is an integral multiple of the fixed value, the reusability of the memory area is increased, and the memory usage efficiency is increased as a whole. In some cases, compaction is not necessary.

  FIG. 30 is a flowchart showing a processing procedure when the object is generated. First, distribution data of the frequency of occurrence of the object size generated so far is obtained (s111). If distribution data has already been obtained by the previous time, it is updated. Subsequently, an area that is free in the memory to be allocated this time and that is larger than the size of the object to be generated is searched, and the object is allocated to a memory area that is an integral multiple of the fixed size (s112 → s113 → s114 → s115). ). Although the above power-of-two byte is a system constant, this value does not necessarily have to be a fixed size and is arbitrary. If the fixed size is too large, small objects will be allocated to large areas. Conversely, if the fixed size is too small, there are areas that cannot be reused for object generation. Will increase. When the fixed size is determined based on the distribution data, it may be determined so that the memory usage efficiency is optimal. Even if the value is not the optimum value, for example, if the value of the power of 2 is taken, there is an effect that it becomes easier to determine the address.

  FIG. 31 is a flowchart showing the processing contents of the program module for determining the occurrence frequency distribution data of the object size and the program module for determining the allocation size of the object. First, a program module for obtaining occurrence frequency distribution data of the object size is loaded (s121), and the program module is activated. That is, until a certain time elapses (for example, until the application program is started / finished 10 times, or for example, 24 hours elapses), the size of each generated object is counted for each size to obtain distribution data. (S122 → s123). Thereafter, the distribution data is registered in the system (s124), and the program module for obtaining the occurrence frequency distribution data of the object size is unloaded (s125). Subsequently, a program module for determining a fixed size is loaded (s126), and the program module is executed. That is, distribution data registered in the system is acquired, a size larger than the distribution center value, for example, a power-of-two byte of 2 is determined as a fixed size, and the value is registered in the system (s127 → s128). Thereafter, the program module for determining the fixed size is unloaded (s129).

  As described above, once the object size distribution is detected and after the fixed size is determined, the program modules for these are unloaded, thereby eliminating the waste of the memory area and CPU power.

  Next, an example in which a fixed size is set by API will be described. FIG. 49 shows an example in which the fixed size is set by the API. As shown in the figure, in the fixed size setting process, a fixed size setting API is called with a fixed size as an argument. In the called API, the argument is registered in the system as a fixed size. When an object is generated, the size of the object is compared with a fixed size (s211). If the size is equal to or smaller than the fixed size, a fixed-size free area on the heap is searched and the found area is assigned to the object (s212 → s213). If the size exceeds the fixed size, an empty area larger than the object size on the heap is searched, and the found area is allocated to the object (s214 → s215).

  Next, another example in which a fixed size is set by API will be described. FIG. 50 shows another example in which the fixed size is set by the API. As shown in FIG. 50, in this example, first, object size distribution data is set by calling an object size distribution setting API. This distribution data is measured in advance by executing a predetermined application for a predetermined time. In response to the call, the object size distribution setting API sets an argument to the object size array variable. Subsequently, a size larger than the center value and a power of 2 bytes is determined as a fixed size, and this is set to a fixed size variable.

Next, an example will be described in which the allocation size of the object is set to several sizes in advance. 51 to 53 are diagrams showing examples in which the object allocation size is determined in advance to several sizes. FIG. 51 shows an object size distribution and a set of divided regions measured by executing a predetermined application for a predetermined time in advance. When the heap area is divided in advance, the distribution of the actual object size is measured, and the division size and the number are determined so as to be close to the distribution. For example, if the heap area is 2 MB, set the partition size specification variable to set No. n bytes k number m
1 64 5000
2 256 10000
3 1k 10000
4 4k 5000
5 32k 500
And

  The division size is set by calling a division size setting API as shown in FIG. As shown in FIG. 53, the called partition size setting API sets an argument to a partition size designation variable and divides the heap area accordingly. That is, first, the loop counter n is set to 0 (s221), and the size k and the number m are obtained from the nth division size designation variable (s222). Subsequently, the area of size k is divided from the heap area into m pieces (m pieces are secured) and registered in the list (s223). This process is repeated while incrementing the loop counter n by 1, and all sizes are divided (s225 → s222 →...). In the above example, when an object having a size exceeding 32 kbytes is generated, the object is allocated to an area other than the divided area in the heap area.

  Next, an example in which the GC efficiency is increased in consideration of the lifetime of the object will be described. FIGS. 32 to 34 are diagrams illustrating an example of performing processing for improving the efficiency of GC in consideration of the lifetime of an object. In the example shown in FIG. 32A, the heap area is divided into an area for generating a short-life object and an area for generating a long-life object, and the class is secured in the long-life area. The class may be secured in other fixed areas. In addition to the definition information as a template for generating an object, the class has a lifetime flag indicating the lifetime of the generated object. This life flag is automatically generated when a class is generated. FIG. 6B is a diagram showing an example of object allocation to the conventional heap area.

  FIG. 33 is a flowchart showing a procedure for deleting an object. As shown in the figure, when an object is deleted, it is determined whether the life of the object is long or short. If the life is short, the life flag of the class of the object is set to short life. For example, the time when the object is generated is stored in the object area, and the lifetime of the object is obtained based on the difference from the time when the object is deleted. The time may be based on the number of times of GC, for example.

  FIG. 34 is a flowchart showing a processing procedure for generating an object. If the life flag of the class indicates a short life, an object is generated in the short life area, and if not, an object is generated in the long life area.

  By dividing the memory allocation area according to the lifetime of the object in this way, fragments can be greatly reduced in the long-life area, and the use efficiency of the memory is improved. Further, for example, by concentrating GC on the lifetime region, CPU power consumed by GC can be reduced.

  Next, the incremental GC by the mark & sweep method will be described with reference to FIGS.

  FIG. 35 is a flowchart showing the overall processing procedure of GC by the mark and sweep method. This GC repeatedly performs clearing of the mark table, marking by the tree search, and erasing (sweeping) of the object.

  FIG. 36 is a flowchart showing the processing content of “mark clear” in FIG. In this process, the contents of the mark table are temporarily cleared. First, the pointer is moved to the head of the mark table (s131), the mark at that position is cleared (s132), and the pointer is moved to the position of the next mark. (S133). This process is repeated for all marks (s134 → s132 →...).

  FIG. 37 is a flowchart showing the processing content of “delete object” in FIG. First, the pointer is moved to the head of the mark table (s141), the presence / absence of the mark is detected, and if not marked, the position in the heap area of the object corresponding to the position on the mark table is calculated. The object is deleted (s142 → s143 → s144). Subsequently, the pointer of the mark table is moved to the next, and the same processing is repeated (s145 → s146 → s142 →...). This leaves the marked object in the mark table and erases other objects from the heap area.

  In order to facilitate the explanation, first, mark provision in the mark & sweep method as a premise will be described.

  FIG. 38 is a diagram showing a procedure for assigning marks by tree search. As shown in (A), a reference relationship represented by a tree structure is traced from the root node 10 to each node, and a mark is given to a node (object) in the reference relationship. Specifically, the bit at the corresponding position on the mark table is set. This tree structure is composed of, for example, the contents of variables provided in an object that indicate which object an object is referring to, and tracing the reference relationship of this object, that is, following the tree is there.

  As shown in (A), an interrupt occurs when a mark is assigned up to node number 3, and by the interrupt processing, an object represented by node number 7 is obtained from the root node as shown in (B). When the reference relationship is broken and the object represented by node number 7 is referenced from the object represented by node number 2, the interrupt process is completed and the process returns to the GC thread to resume the mark assignment. In this case, since the reference relationship from the root node to the object represented by the node number 7 is broken, the pointer is returned to the root node as shown in (C) and the process proceeds to the node number 8 in the next reference relationship. It will be. At this time, the node numbers 5 and 6 are not marked. Therefore, for an object whose reference relationship has been changed, it is necessary to trace a tree from the object and mark the object referenced from the object.

  FIG. 39 is a flowchart showing the processing content of “object generation”. First, a system lock is activated for the kernel (s151), a free area in the heap area is searched (s152), and a necessary size is allocated to an area larger than the size of the object to be generated (s153 → In step s154, a reference change mark is added (write barrier) (s155), and the system is unlocked (s156).

  FIG. 40 is a flowchart showing the processing procedure of “reference change mark assignment”. First, the position on the mark table is calculated from the reference-changed object, and it is determined whether or not the corresponding mark is white. This White mark is represented by 2 bits of 00, for example, and means that the mark is not marked yet. If it is not the White mark, it has already been marked, so the processing ends. If it is a White mark, mark it as Gray. This Gray mark is represented by 2 bits of 01, for example, and means that the object has been changed in reference. When calculating the position of the mark from the object, for example, it is performed by adding 1/8 the address of the object and adding an offset, or by calculating the serial number of the object.

  FIG. 41 is a flowchart showing the processing procedure of “mark addition by tree search”. First, the pointer for tracing the tree is moved to the root node of the tree (s161), and a mark corresponding to the newly generated object is assigned (s162). Subsequently, the tree is traced to move the pointer to the next object (s163), and this process is repeated until the end of the tree (s164 → s162 →...). Thereafter, the pointer is moved to the head of each thread stack (s165), and a mark corresponding to the object on the stack is given (s166). Thereafter, the pointer is moved next to the stack (s167), and this process is repeated until the end of the tree (s168 → s166 →...). Thereafter, the process moves to the next thread stack (s169), and the same processing is repeated until the end of the thread stack (s170 → s166 →...). Further, this thread stack is processed for all thread stacks (s171 → s172 → s165 →...). In this series of tree searches, if the Gray mark is detected even once in the middle, the search and mark assignment are performed again from the root node (s173 → s161 →...).

  FIG. 42 is a flowchart showing the processing procedure of “marking corresponding to object” in FIG. In this process, the position on the mark table is calculated from the generated object, and a black mark is assigned. This black mark is represented by 2 bits of 1x, for example, and means a marked state.

  In the mark assigning method as described above, if an interrupt is applied in the middle of the change and the object reference relationship changes, a Gray mark is assigned, and thus the tree search must be repeated. In some cases, mark assignment is not completed indefinitely, and GC is not performed indefinitely.

  FIG. 43 is a diagram showing a procedure of “mark addition by tree search” for solving the above problem. (A) shows a state when the reference relationship is changed due to an interruption in the state of (A) shown in FIG. In this way, an interrupt is generated when the mark is assigned up to the node number 3, and the reference process from the root node to the object represented by the node number 7 is cut off by the interrupt process, and the node number 2 If the object represented by the node number 7 is referred to from the object represented by (2), the data representing the node number 7 of the reference destination is loaded on the mark stack. After that, when the interrupt process is completed and the process returns to the GC thread and the mark assignment is resumed, the reference relationship from the root node to the object represented by the node number 7 is cut off, as shown in (B). Return the pointer to the root node to mark node number 8 in the next reference relationship. At this point, the tree search is completed, and thereafter, as shown in (C), a mark is given to an object having a reference relationship by tracing the tree from the node indicated by the contents of the mark stack. As a result, as shown in (D), mark assignment for all objects in the reference relationship is completed.

  FIG. 44 is a flowchart showing the processing procedure of “reference change mark assignment”. In this manner, data indicating the object whose reference has been changed is stacked on the mark stack. The object generation process is the same as that shown in FIG.

  FIG. 45 is a flowchart showing a processing procedure of “mark addition by tree search”. Steps s161 to s172 are the same as steps s161 to s172 in the flowchart shown in FIG. In the example shown in FIG. 45, after completing the tree search for all thread stacks, data is extracted from the mark stack (s181 → s182), and a mark is assigned to the object indicated by the data (s183). The object is traced from the object through the tree to the end of the tree (s184 → s185 → s183 →...). This process is repeated while updating the pointer of the mark stack until the mark stack becomes empty (s181 → s182 →...).

  FIG. 46 is a flowchart showing the processing procedure of “marking corresponding to object” in FIG. In this process, the position on the mark table is calculated from the generated object, and a mark is given.

  By using the mark stack in this way, it is not necessary to restart the tree search from the root node, and the overall processing time required for mark assignment can be greatly shortened.

FIG. 47 and FIG. 48 are flowcharts for further eliminating unnecessary processing time when the mark is applied using the mark stack.
FIG. 47 is a flowchart showing the processing procedure of “reference change mark assignment”. First, the position on the mark table is calculated from the object whose reference is changed, and it is determined whether or not the corresponding mark is white (s191 → s192). This White mark means that the mark has not been marked as described above. If it is not the White mark, it has already been marked, so the processing ends. If it is a white mark, it is marked as gray (s193). As described above, this Gray mark means an object whose reference has been changed. Subsequently, data indicating the reference destination object is loaded on the mark stack (s194).

  FIG. 48 is a flowchart showing the processing procedure of “marking corresponding to an object”. In this process, the position on the mark table is calculated from the generated object, and a black mark is assigned. This black mark means a marked state as described above. The “object generation” process is the same as that shown in FIG.

  In this way, when a mark is assigned to an object whose reference has been changed, the mark is attached only when the object is the first detected object, so the time and mark required for tree search based on the contents of the mark stack The time required for reading the stack can be shortened.

  The mark for the object whose reference has been changed may not be stored in the stack, but a FIFO buffer may be used.

  In the embodiment, the mark is added to the mark table. However, mark information may be provided inside the object to directly add the mark to the object.

The block diagram which shows the structure of the hardware of the apparatus which concerns on embodiment Block diagram showing the software configuration of the device Diagram showing the reference relationship between objects and the relationship with each thread's stack Functional block diagram of software Diagram for explaining the effect of compaction The figure which shows the example of the change of the processing content of the thread by the presence or absence of context switch Flow chart showing processing procedure of exclusive control A flowchart showing a processing procedure related to an API for detecting whether or not a context switch has occurred Flow chart showing processing procedure of context switch Flow chart showing the compaction process The flowchart which shows the processing procedure of GC by the copying method Flowchart showing processing procedure of exclusive control in copying method GC The flowchart which shows the processing procedure of the other exclusive control in the copying method GC The flowchart which shows the process sequence regarding API for exclusive control in FIG. The flowchart which shows the process sequence regarding API for exclusive control in FIG. The figure which shows the example of the automatic switching of the priority of GC thread | sled Flowchart for switching thread priority values and priority times The figure which shows the example which changed the high priority time of GC thread Flow chart for making it possible to change the high priority time of the GC thread Flowchart showing an example of automatically changing the high priority time of the GC thread The figure which shows the example which changed the switching cycle of the high / low priority time of GC thread Flowchart for changing the switching cycle of the GC thread high / low priority time The figure which shows the example of irregular GC processing Flowchart corresponding to FIG. The figure which shows the example of the forced change of the priority of the GC thread by exclusive control API Flowchart for forcibly changing the priority of a GC thread by exclusive control API The flowchart which shows the process sequence which switches the algorithm of GC The figure which shows the example of size distribution of the object which is generated Figure showing an example of memory allocation size of an object Flow chart showing the object generation process Flow chart regarding object size distribution detection and fixed size determination processing Diagram showing heap area configuration Flow chart showing the procedure for erasing objects Flow chart showing object generation procedure Flowchart showing GC procedure by mark & sweep method Flow chart showing mark clear processing procedure Flow chart showing object erasure processing procedure The figure which shows the example of mark grant by tree search Flowchart corresponding to FIG. Flowchart corresponding to FIG. Flowchart corresponding to FIG. Flowchart corresponding to FIG. The figure which shows the example of mark grant by tree search Flowchart corresponding to FIG. Flowchart corresponding to FIG. Flowchart corresponding to FIG. Flowchart showing another processing procedure for adding a reference change mark Flowchart showing another processing procedure for adding a mark corresponding to an object Flow chart showing processing procedure for fixed size setting and object generation Flow chart showing processing procedure for object size distribution setting Figure showing examples of object size distribution and division size Flow chart showing the processing procedure related to object generation and processing to divide the heap area by a predetermined size The flowchart which shows the processing procedure regarding the processing which divides the heap area with the predetermined size Flowchart showing the procedure of GC by the conventional mark & sweep method

Claims (10)

Characteristic detection means for detecting characteristics of objects generated in the heap area of the memory;
A memory allocation device comprising: an allocation determination unit that determines allocation of the object to the heap area according to the characteristic detected by the characteristic detection unit. The characteristic detection means is means for detecting a distribution of size of objects allocated in the heap area,
2. The memory allocation apparatus according to claim 1, wherein the allocation determination unit includes an allocation size determination unit that determines an integer multiple of a fixed size larger than the center of the distribution as an allocation size of a new object for the heap area. 3. The memory allocation device according to claim 2, wherein the characteristic detection unit is a program module that is incorporated in the system at the start of use of the system and is separated from the system after detecting the size distribution of the object. 3. The memory allocation device according to claim 2, wherein the allocation size determination means is a program module that is incorporated in the system at the start of use of the system and is disconnected from the system after the fixed size is determined. Heap area dividing means for dividing the heap area into a plurality of sizes in advance;
3. The memory allocation apparatus according to claim 2, further comprising means for allocating an area having a size that is larger than and smaller than the size of the object. 6. The memory allocation device according to claim 5, wherein the heap area dividing unit is a unit that divides the heap area by calling an application program interface using the division number of the plurality of sizes and each size as an argument. 3. The memory allocation apparatus according to claim 2, further comprising means for setting the fixed size by calling an application program interface. Storing data corresponding to the time when the object is generated from the class, and when deleting the object, comprising means for detecting the life of the object and providing the data of the life in the class,
The characteristic detection means is means for detecting the lifetime of an object generated from a class,
2. The memory allocation device according to claim 1, wherein the allocation determination unit is a unit that determines an object generation area for the heap area to be allocated to the object based on the lifetime of the object detected by the characteristic detection unit. A first step of detecting characteristics of an object generated in a heap area of memory;
A memory allocation method for causing a computer to execute a second step of determining allocation of the object to the heap area according to the characteristic detected by the first step. A first step of detecting characteristics of an object generated in a heap area of memory;
A computer-readable recording medium recording a processing program for causing a computer to execute a second step of determining allocation of the object to the heap area according to the characteristic detected by the first step.

Images