JP4935626B2 - Control program and method, and computer - Google Patents

Description

  The present invention relates to a technique for controlling execution of a plurality of functions included in a program executed on a virtual machine and executed as a thread.

  Language processing systems (Java (registered trademark) and .NET) that operate on virtual machines are common, memory acquisition and release are automated, and are effective in development and memory leak prevention. On the other hand, there is no API (Application Program Interface) set that controls the memory area managed by the virtual machine on the application side. Even if a memory consumption problem occurs during operation, the cause is identified, concurrent execution control, and function improvement There is no systematic way to implement these.

  If it is under development, it is possible to measure the memory consumption for each single function using an existing product such as a profiler and identify the cause, but multiple functions are executed in parallel during actual operation. Therefore, it is impossible to specify the memory consumption. Moreover, it is not realistic to use a function with a large overhead like a profiler during actual operation.

Japanese Patent Application Laid-Open No. 2006-285871 discloses a technique for reducing the possibility that an information processing apparatus will not be able to start an application due to a memory shortage, and avoiding the inconvenience that a new application cannot be started or installed. Is disclosed. Specifically, an information processing apparatus that manages the amount of memory used by a plurality of applications includes an acquisition unit that acquires the maximum memory usage for each application, and a sum of the maximum memory usage for each application acquired by the acquisition unit. A calculating means for calculating, and a control means for determining whether or not the application can be started based on whether or not the sum of the maximum memory usage for each application calculated by the calculating means exceeds an allowable amount when the application is requested to start. Prepare.
JP 2006-285871 A

  FIG. 1 schematically shows OS (Operating System) memory management. The OS allocates a dedicated memory area in the memory area managed by the OS for each process (including a virtual machine) such as an application executed on the OS. In the example of FIG. 1, processes 1 to n exist, each of which has a process 1 dedicated memory area, a process 2 dedicated memory area,. . . A process n dedicated memory area is secured. In this way, a dedicated memory area is allocated for each process, so that if the size of the memory area can be specified, the OS can easily specify the remaining memory capacity. The above publication is also described under such a premise.

  However, for each function included in a program executed on a virtual machine on the OS and executed as a thread, unlike the OS shown in FIG. 1, the memory consumption cannot be easily specified. Specifically, the virtual machine provides a memory area allocated from the OS so that each thread can use it, but provides a shared memory area (heap area) separately from a stack area dedicated to each thread. Each thread uses this shared memory area as needed when necessary. In the example of FIG. 2, the thread 3 uses the shared data B alone, but the shared data A is shared by the threads 1 and 2, and the thread 2 uses the shared data A and C. Yes. Thus, the memory capacity used by one thread cannot be completely separated and specified.

  More specifically, a case is assumed in which the first thread shown in FIG. 3A and the second thread shown in FIG. Here, the remaining amount of memory (the remaining amount of memory in the memory area managed by the virtual machine) at the start of the first thread (MA-1) and the start of the second thread (MB-1) is “10000”. It is assumed that the remaining memory capacity at the end of the first thread (MA-2) and the end of the second thread (MB-2) is “8950”. The remaining memory capacity can be acquired from the virtual machine. On the other hand, in reality, the memory consumption of the first thread A-1 to A-3 is “100”, “200”, “300” and the total “600”, and the second thread B-1 to Even when the memory consumption in B-3 is “250”, “50”, “150” and the total is “450”, only the remaining memory amount as described above can be specified without modifying the OS or the virtual machine The memory consumption amount of the first thread and the memory consumption amount of the second thread can be calculated only as “10000” − “8950” = “1050”.

  Thus, conventionally, there is no idea of specifying the memory consumption of each function that is included in a program executed on a virtual machine and executed as a thread, and even an appropriate reasonable value Could not be calculated. Therefore, when a new thread is executed, it has not been possible to appropriately determine whether or not there is no problem in executing the thread. Further, it may be possible if the OS and the virtual machine can be modified, but the modification takes a lot of time and is not realistic in the current situation where a general-purpose OS or virtual machine is often used.

  Therefore, an object of the present invention is to provide a technique for appropriately controlling the execution of each function that is included in a program executed on a virtual machine and executed as a thread without modifying the OS or the virtual machine. That is.

  Another object of the present invention is to provide an appropriate measure of the memory consumption of each function that is included in a program executed on a virtual machine and is executed as a thread without modifying the OS or the virtual machine. It is to provide a technology for making it possible.

  A control program according to the present invention is a control program that is included in a program executed on a virtual machine and controls the execution of a plurality of functions that are executed as threads, and is transmitted from a virtual machine to a specific processor. From the step of acquiring the remaining amount of memory allocated to the virtual machine at the start of function execution and the memory consumption table by function that stores the estimated memory consumption of each function executed in the past, Extracting the estimated memory consumption for a specific function, calculating a predicted memory consumption value for the specific function from the extracted estimated memory consumption, a remaining memory amount and a predicted memory consumption value, If the difference is less than a predetermined threshold value, a step of causing the virtual machine to stop a thread having a specific function is executed.

  A memory consumption prediction value of a specific function is calculated by a control program different from the OS and the virtual machine, and execution control of the specific function is appropriately performed based on the difference between the remaining amount of memory and the memory consumption prediction value. Will be able to.

  When the difference between the remaining amount of memory and the predicted memory consumption value is equal to or greater than a predetermined threshold, the control program is executing data related to a thread with a specific function, including the remaining amount of memory. A step of registering in the executing thread table storing data relating to the thread of the function of the second, and a second of the memory that is the remaining amount of memory allocated to the virtual machine at the end of execution of the specific function from the virtual machine A step of obtaining a remaining amount, a step of obtaining a remaining amount of memory of a specific function from an executing thread table, and a net memory consumption which is a difference between a second remaining amount of memory and a remaining amount of memory, The estimated memory consumption for a specific function is calculated by apportioning it between the specific function and the other function that is specified from the executing thread table and is being executed at the same time. And Estimated memory consumption calculating step of, further to execute a measure memory consumption and registering by function memory consumption table for a particular function.

  In this way, the estimated memory consumption of a specific function can be calculated. For example, it is possible to analyze a memory consumption table for each function, extract problematic functions, and make improvements. Become.

  Further, the memory consumption prediction value calculating step described above calculates the average value of the extracted standard memory consumption, and the absolute difference between the extracted standard memory consumption and the average value of the standard memory consumption. You may make it include the step which calculates the predetermined ratio of the average value of a value as a dispersion | distribution risk value, and the step which calculates the sum of the average value of standard memory consumption, and a dispersion | distribution risk value as a memory consumption prediction value. A configuration in which the threshold value is adjusted by that amount without adding the variance risk value is also possible.

  In addition, the reference memory consumption calculation step described above obtains the average value of the reference memory consumption of a specific function (for example, it may be calculated from the memory consumption table by function, or the data held in the cache) The average memory consumption is acquired for each of the other functions that are specified from the executing thread table and other functions that are executed simultaneously with the specific function (for example, memory consumption by function) (It may be calculated from the amount table or the data held in the cache may be read out), the average value of the estimated memory consumption of a specific function, and the estimated memory consumption of each of the other functions And calculating a reference memory consumption amount of a specific function by apportioning the pure memory consumption amount with a predetermined ratio of the average value. The predetermined ratio is set according to, for example, the degree of simultaneous execution of simultaneous execution threads.

  In addition, the memory consumption prediction value calculation step described above calculates the estimated memory consumption for a specific function from the memory consumption table for each function that stores the estimated memory consumption for each function executed in the past. A step of determining whether a predetermined number of executions have been extracted may be included. If the target memory consumption cannot be extracted for the predetermined number of executions, the data related to the thread of the specific function including the remaining memory capacity is registered in the executing thread table that stores the data related to the thread of the function being executed. This step may be further executed. This defines the processing when data is not sufficiently stored in the function-specific memory consumption table.

  The program is stored in a storage medium or storage device such as a flexible disk, CD-ROM, magneto-optical disk, semiconductor memory, or hard disk. Moreover, it may be distributed as a digital signal via a network or the like. The intermediate processing result is temporarily stored in a storage device such as a main memory.

  According to the present invention, it is possible to appropriately control the execution of each function that is included in a program executed on a virtual machine and executed as a thread without modifying the OS or the virtual machine.

  In addition, according to another aspect of the present invention, an appropriate measure of the memory consumption of each function that is included in a program executed on a virtual machine and executed as a thread without modifying the OS or the virtual machine. Will be able to give.

  FIG. 4 shows a program configuration according to an embodiment of the present invention. As shown in FIG. 4, the virtual machine 10 is executed as one process on the OS 1. The OS 1 allocates a dedicated memory area to the virtual machine 10, and the virtual machine 10 is executed using the dedicated memory area. Various threads are activated on the virtual machine 10. For example, a server program 11 that implements reception of a request, determination of a function to be executed, call of an execution function, and the like, which are called by the server program 11, for example, are memory consumption measurement targets and thread activation control targets. The measurement target program 12 is executed as a thread on the virtual machine 10. Furthermore, the memory management module 14 that is called from the measurement target program 12 and performs the main processing in the present embodiment, and various libraries 13 that are used by the measurement target program 12 are also executed on the virtual machine 10. Note that, as will be described below, a code for calling the memory management module 14 is automatically added to the measurement target program 12 at the time of compilation, and execution control is performed by the called memory management module 14. The memory management module 14 performs processing using the function-specific memory consumption table 141 and the executing thread table 142. Further, the function-specific average memory consumption table 143 may be used.

  FIG. 5 shows an example of the function-specific memory consumption table 141. Each time a predetermined function executed as a thread of the measurement target program 12 is executed, one record is generated. In the example of FIG. 5, for each record, a serial number and a function ID (for example, Java (registered) In the case of trademark), the package name, class name # method name, in the case of C #, the name that uniquely represents a function or subroutine such as namespace name.class name # method name), time, and approximate memory consumption It comes to register.

  FIG. 6 shows an example of the executing thread table 142. The currently executing thread table 142 is listed in the executing thread table 142. In the example of FIG. 6, the thread ID, the function ID, the start memory remaining amount, and the simultaneous execution are executed for each thread being executed. Function names are registered.

  FIG. 7 shows an example of the average memory consumption table 143 classified by function. Although there is a method that does not use this table, the use of this table speeds up the processing. In the average memory consumption table by function 143, one record is registered for each function, the function ID, the average memory consumption (described in detail below), the last update time, Is to be registered. For records whose last update time is older than a predetermined reference, it is preferable to calculate the average memory consumption separately without using the records.

Note that a program (for example, the server program 11 or the like) operating on the virtual machine can command the virtual machine 10 as follows.
A program can generate and extinguish threads by instructing the virtual machine 10.
The program can stop the currently executing thread and re-execute the stopped thread by instructing the virtual machine 10.
The program can instruct the virtual machine 10 to use the memory area (place data in the memory area).
The program can know “total memory area” and “memory area usage” by making an inquiry to the virtual machine 10. That is, the remaining memory capacity can be grasped.
The program can instruct the virtual machine 10 to wait for the start of the procedure of the program currently being executed by the own thread when another thread tries to execute it (exclusive control is performed).

  Next, details of the program configuration shown in FIG. 4 will be described with reference to FIG. The server program 11 receives a request, determines a function to be executed, and calls a function to be executed. In the example of FIG. 8, a function 21 called function ID: com.fuji.xxx.XClass # FunctionA and a function 22 called function ID: com.fuji.xxx.XClass # FunctionB are called in response to a request. Which function or subroutine is defined as a function is arbitrary, and is preferably set in a unit in which memory consumption is to be measured or a unit suitable for controlling the activation of a thread. However, in actuality, in application development, class names and method names are assigned according to certain rules, so that functions can be defined according to the rules.

  The function 21 includes a function start processing unit 211, an original processing unit 212, and a function end processing unit 213. In the present embodiment, the function start processing unit 211 and the function end processing unit 213 are portions that are automatically embedded in the original processing unit 212 by an aspect-oriented technique or the like, for example, and call the memory management module 14. The original processing unit 212 is a part that performs the original processing of the function 21. The common processing module 23 may be called as necessary.

  Similarly, the function 22 includes a function start processing unit 221, an original processing unit 222, and a function end processing unit 223. In the present embodiment, the function start processing unit 221 and the function end processing unit 223 are parts that are automatically embedded in the original processing unit 222 by aspect-oriented technology or the like, for example, and call the memory management module 14. The original processing unit 222 is a part that performs the original processing of the function 22. The common processing module 23 may be called as necessary.

  Next, the outline of the processing of the program shown in FIG. 8 will be described with reference to FIG. First, the execution of the server program 11 is started in the thread 1, and for example, a function execution request from an end user is awaited and stopped (server program procedure 1). Here, when a function execution request is received from the end user, the server program 11 resumes processing and performs function determination processing (server program procedure 2). When the function to be executed is specified, a new thread 2 is generated for the virtual machine 10 for parallel processing, and the function to be executed is executed (server program procedure 3). Thereafter, the thread 1 returns to the server program procedure 1. When the execution of the function in the thread 2 is completed, the server program 11 may also execute a termination process. However, the description is omitted here because it is not the main point of the present embodiment.

  For example, the function 21 is assumed to be executed in the thread 2 generated by the virtual machine 10 according to the instruction of the server program 11. In the function 21, the call code of the memory management module 14 is first executed in the function start processing unit 211, and the function start process of the memory management module 14 is executed (program procedure M-1). The function start processing of the memory management module 14 will be described in detail later. When the function start processing of the memory management module 14 is completed, processing (procedures A-1 to A-4) by the original processing unit 212 is executed. In addition, as shown in FIG. 8, you may make it call the common processing module 23 as needed.

  When the processing of the original processing unit 212 is completed, the calling code of the memory management module 14 in the function end processing unit 213 of the function 21 is executed, and the function end processing of the memory management module 14 is executed (program procedure M- 2). The function end processing of the memory management module 14 will be described in detail later. Then, the execution of the thread 2 is terminated, and the thread 2 is extinguished by the virtual machine 10.

  Hereinafter, the function start processing of the memory management module 14 will be described in detail with reference to FIGS. First, the memory management module 14 outputs another thread exclusive instruction to the virtual machine 10 (step S1). Thus, even if the memory management module 14 is called in another thread, the function start processing of the memory management module 14 is not executed except for this thread until the other thread exclusion release command is issued.

  Next, the memory management module 14 acquires the remaining memory capacity from the virtual machine 10 (step S3). The existing function of the virtual machine 10 is used. Then, the memory management module 14 performs a function-specific memory consumption predicted value calculation process (step S5). This function-specific memory consumption predicted value calculation processing will be described with reference to FIGS.

  First, the memory management module 14 searches the function-specific memory consumption table 141 based on the function ID and the prediction target period, and extracts a corresponding record (step S21). The function ID is acquired from the function start processing unit 211 of the function 21 when the memory management module 14 is called, for example. The prediction target period is one of the setting parameters of the memory management module 14 as shown in FIG. 12, and a numerical value such as one week (= 604800 seconds) is set. An example of the record extracted in step S21 is shown in FIG. Here, it is assumed that 8 records have been extracted.

  Then, the memory management module 14 determines whether or not a record equal to or greater than the stop determination threshold is extracted (step S23). The stop determination threshold is one of the setting parameters of the memory management module 14 as shown in FIG. 12, and a numerical value such as “5” is set, for example. If no record equal to or greater than the stop determination threshold has been extracted, the number of cases is small and the prediction accuracy is low, so the thread stop is not required and the process returns to the original process (step S25).

  On the other hand, if a record equal to or greater than the stop determination threshold value can be extracted, the memory management module 14 calculates an average memory consumption value from the extracted record and stores it in a predetermined memory area (step S27). In the example of FIG. 13, since the stop determination threshold is “5” and the number of extracted records is “8”, the average value of the memory consumption is calculated. In the example of FIG. 13, the memory consumption average value is calculated as “9750”. Note that the memory consumption average value calculated in this step may be registered in the function-specific average memory consumption table 143 and used later.

  Further, the memory management module 14 calculates an average of absolute values of differences between the memory consumption average values of the memory consumption in the extracted record and stores the average in a predetermined memory area (step S29). In the example of FIG. 13, the absolute value of the difference from the memory consumption average value is “2250” “2750” “250” “750” “250” “1250” “1750” “1250” in order from the top. Therefore, this average is calculated as “1312.5”.

  Then, the memory management module 14 calculates a dispersion risk value by the product of the average of the absolute value of the difference and the allowable dispersion value, and stores it in a predetermined memory area (step S31). The dispersion allowable value is one of the setting parameters of the memory management module 14 as shown in FIG. 12, and a numerical value such as “0.8” is set, for example. The variance risk value corresponds to a margin from the average memory consumption. In the example of FIG. 13, 1312.5 × 0.8 = 1050 is calculated as the variance risk value. After that, the memory management module 14 calculates a function-specific memory consumption predicted value based on the sum of the memory consumption average value and the variance risk value, and stores it in a predetermined memory area (step S33). In the example of FIG. 13, the memory consumption prediction value by function is calculated as 9750 + 1050 = 10800. Then, the process returns to the original process.

  Returning to the description of FIG. 10, the memory management module 14 determines whether it is necessary to stop this thread (thread 2) (step S7). In this step, if thread stop unnecessary is set in step S25, it is determined that thread stop is unnecessary. In other cases, the remaining memory capacity acquired in step S3 and the memory consumption by function calculated in step S33 are determined. It is determined whether or not the difference from the predicted value is smaller than the allowable amount of remaining memory, and if it is smaller, it is determined that the thread must be stopped because memory shortage is predicted. On the other hand, if the difference between the remaining amount of memory and the predicted memory consumption by function is equal to or larger than the allowable amount of remaining memory, it is determined that thread stop is unnecessary. The memory remaining capacity is one of the setting parameters of the memory management module 14 as shown in FIG. 12, and a numerical value such as “1000” is set, for example. For example, if the remaining memory capacity is “20000”, in the example of FIG. 13, “20000” − “10800” = “9200”, which is larger than the allowable memory remaining capacity, it is determined that it is not necessary to stop the thread. Is done.

  If it is determined in step S7 that the thread must be stopped, the memory management module 14 outputs the other thread exclusion release instruction and the stop instruction for this thread (thread 2) to the virtual machine 10 (step S9). Then, the process returns to step S1. As a result, the virtual machine 10 releases the exclusive state of the memory management module 14 and permits execution by other threads. Furthermore, the execution of the thread 2 is stopped.

  On the other hand, if it is determined that thread stop is unnecessary, the memory management module 14 additionally registers this function ID in the simultaneous execution function of all the records in the executing thread table 142 (step S11). For example, when the executing thread table 142 as shown in FIG. 14 exists before execution of step S11, the execution thread table is changed to the executing thread table as shown in FIG. 15 by executing step S11. That is, assuming that the function being executed in the thread 2 is FuncA (or FunctionA), FuncA is additionally registered in the concurrent execution function name column of each record in the executing thread table (in bold).

  Further, the memory management module 14 registers the data for this thread in the executing thread table 142 (step S13). That is, the state shown in FIG. 16 is obtained. Specifically, the thread ID “3”, the function ID “FuncA”, the remaining memory capacity “20000” at the start time, and the simultaneous execution functions “FuncX, FuncY” are registered (bold). Note that the function IDs in the first and second rows that have already been registered are registered for the column of simultaneous execution functions.

  Then, the memory management module 14 outputs a virtual thread exclusion release command to the virtual machine 10 (step S15). As a result, the memory management module 14 can be called in another thread. Then, the original processing of the function 21 is executed.

  By executing the above process, if it is determined that there is sufficient memory, the thread will continue to be executed. If memory shortage is predicted, the thread will be stopped and the entire system will be stopped. The operation of can be stabilized.

  In this embodiment, when calculating the memory consumption predicted value by function, a method of calculating the variance risk value and adding it to the memory consumption average value is adopted. It is also possible to use a method in which the determination is made by adding an appropriate memory capacity to the memory remaining capacity allowable value without adopting. Furthermore, the setting parameters need to be set appropriately according to the execution environment, and the example of FIG. 12 is an example.

  Next, the function end process of the memory management module 14 will be described with reference to FIGS. The memory management module 14 outputs another thread exclusive command to the virtual machine 10 (step S41). This is the same as step S1. Then, the memory management module 14 reads the remaining memory capacity at the start of this function from the executing thread table 142 (step S43). In the executing thread table 142 as shown in FIG. 16, data “20000” of the memory remaining at the start time is read from the third line.

  Then, the memory management module 14 acquires the current memory remaining amount from the virtual machine 10 as the end-time memory remaining amount (step S45). For example, it is assumed here that data “4000” has been acquired. In this embodiment, it is assumed that the memory allocated to the virtual machine 10 by various functions is consumed and the remaining memory capacity is reduced. However, garbage collection may be performed by the memory management unit included in the virtual machine 10 to increase the remaining memory capacity. In such a case, the estimated memory consumption cannot be calculated by the following process. In such a case, the process proceeds to step S51.

  Then, the memory management module 14 performs a standard memory consumption calculation process (step S47). The reference memory consumption calculation process will be described with reference to FIG. First, the memory management module 14 subtracts the end point memory remaining amount from the start point memory remaining amount, calculates the net memory consumption, and stores it in a predetermined memory area (step S61). In the above example, “20000” − “4000” = “16000” is calculated. However, the net memory consumption includes the amount consumed by other functions.

  Next, the memory management module 14 specifies all simultaneous execution functions from the executing thread table 142 (step S63). All concurrent execution functions are specified, including the function being executed in this thread. In the example of FIG. 15, three functions (FuncX, FuncY, and FuncA) are specified. And one unprocessed thing is specified among all simultaneous execution function ID (step S65). Further, the function-specific memory consumption table 141 is searched with the specified function ID and the prediction target period (FIG. 12), and the corresponding record is specified (step S67). Processing similar to that in step S21 is performed. Then, the memory management module 14 determines whether a record equal to or greater than the stop determination threshold value (FIG. 12) has been extracted (step S69). If records exceeding the stop judgment threshold cannot be extracted, it is considered inappropriate to calculate the average memory consumption, and the memory consumption of all the concurrent execution functions is assumed to be the same value, and the net memory consumption is prorated. As a result, the estimated memory consumption is calculated (step S71). Then, the process proceeds to the original process.

  On the other hand, if a record equal to or greater than the stop determination threshold value can be extracted, the memory management module 14 calculates the memory consumption average value by averaging the memory consumption in the extracted records, and stores it in a predetermined memory area. Store (step S73).

  Then, the memory management module 14 determines whether processing has been performed for all simultaneous execution functions (step S75). If there is an unprocessed function, the process returns to step S65.

  Thus, in the example described above, the memory consumption average value of FuncX (for example, “5000”), the memory consumption average value of FuncY (for example, “6000”), and the memory consumption average value of FuncA (for example, “ 9750 ") is calculated. When the average memory consumption table by function 143 is used, it is checked after step S65 whether a calculation result within a predetermined time (that is, an average value of memory consumption) is stored. Steps S67 to S73 may be skipped if they exist, and steps S67 to S73 described above may be executed if there are no calculation results within a predetermined time. In addition, when steps S67 to S73 are executed, the calculated memory consumption average value is registered in the function-specific average memory consumption table 143.

  When the processing for all the simultaneous execution functions is completed, the memory management module 14 virtually calculates the reference memory consumption by dividing the net memory consumption virtually by using the memory consumption average value of all the simultaneous execution functions. Calculate and store in a predetermined memory area (step S77). Specifically, pure memory consumption (16000) × memory consumption average value of this function (9750) / (memory consumption average value of this function (9750) + (memory of first simultaneous execution function (FuncX)) (Consumption average value (5000)) / 2+ (memory consumption average value of second concurrent execution function (FuncY) (6000)) / 2+...) = “10229”. The reason why the average memory consumption of the first and second simultaneous execution functions is divided by “2” is based on the assumption that the threads executing these functions are executing about 50%. Is. The reason for virtually allocating in this way is that it is impossible to completely discriminate how much the memory consumption of the concurrent execution function contributes to the net memory consumption. Accordingly, the estimated memory consumption is not an accurate value, but if it can be calculated with a certain degree of accuracy, the thread execution can be controlled with a certain degree of accuracy even in the function start processing. Further, by separately analyzing the memory consumption table for each function 141, for example, it is possible to extract a problem such as a particularly large amount of reference memory consumption for a specific function, and further to determine improvement of the program. become.

  Returning to the processing of FIG. 17, the memory management module 14 adds a record to the function-specific memory consumption table 141 (step S49). For example, a record as shown in the last line (serial number 100) in FIG. 19 is added. Further, the memory management module 14 deletes the record corresponding to this thread from the executing thread table 142 (step S51). For example, as shown in FIG. 20, the record in the last line is deleted.

  Finally, the memory management module 14 outputs another thread restart command to the virtual machine 10 (step S53). Thereby, for example, the thread that has been stopped in step S9 is restarted. Further, the memory management module 14 outputs a virtual thread exclusion release command to the virtual machine 10 (step S55).

  By performing the function end process as described above, the function-specific memory consumption table 141 is updated, and more appropriate thread execution control can be performed in the subsequent function start process. Further, by separately analyzing, it becomes possible to take measures such as identifying and repairing the problematic function.

  Further, when the example of FIG. 3 is processed according to the present embodiment (the memory consumption average value of functions executed in the first thread is “550”, the memory consumption of functions executed in the second thread) For the function executed in the first thread, the average value is “500”. (10000-8950) × 550 / (550 + 500/2) = 722, and the function executed in the second thread Is (10000-8950) × 500 / (500 + 550/2) = 677. Thus, although there is a difference from the assumed memory consumption shown in the example of FIG. 3, it is more appropriate than using the difference (= 1050) between the memory remaining amount at the start time and the memory remaining amount at the end time. A reasonable amount of memory consumption can be obtained. Note that it is difficult to grasp the estimated memory consumption as described above during actual operation.

  Note that an existing aspect-oriented compiler may be used to set the call relationship to the memory management module 14 as described above in the measurement target program 12. For example, as shown in FIG. 21, when the source code of the measurement target program 12 and the attachment location information of the memory management module 14 are input to an aspect-oriented compiler, the measurement target into which the calling code of the memory management module 14 is inserted. A program 12 (execution module) is generated. The attachment location information may be a list of “source code file name + function name”, for example. However, the attachment location is a function that becomes the start point and end point of the function for the purpose of this embodiment. In many cases, a source code file name or a function name having such a function is attached in accordance with a predetermined rule in consideration of maintenance in developing a program. Therefore, in reality, it is possible to specify the attachment location in the form of “all the“ execute ”functions of the source code file name“ ˜Function ”” ”.

  Although one embodiment of the present invention has been described above, the present invention is not limited to this. For example, FIG. 4 shows an example in which the function-specific memory consumption table 141, the executing thread table 142, and the function-specific average memory consumption table 143 are provided in the memory management module 14, but as shown in FIG. For example, the database server 30 that manages the table may be provided on the virtual machine 10 as another thread, or may be provided on another computer.

  In addition, if the processing result does not change, the order of the processing steps may be changed.

  Moreover, although the example using the server program 11 was shown, the server program 11 is not necessarily used.

  As shown in FIG. 23, the computer executing the program such as the OS described above is connected to a memory 2501 (storage unit), a CPU 2503 (processing unit), a hard disk drive (HDD) 2505, and a display device 2509. The display control unit 2507, the drive device 2513 for the removable disk 2511, the input device 2515, and the communication control unit 2517 for connecting to the network are connected by a bus 2519. Application programs including the OS and the Web browser are stored in the HDD 2505, and are read from the HDD 2505 to the memory 2501 when executed by the CPU 2503. If necessary, the CPU 2503 controls the display control unit 2507, the communication control unit 2517, and the drive device 2513 to perform necessary operations. Further, data in the middle of processing is stored in the memory 2501 and stored in the HDD 2505 if necessary. Such a computer realizes various functions as described above by organically cooperating hardware such as the CPU 2503 and the memory 2501 described above with the OS and necessary application programs.

(Appendix 1)
A control program that is included in a program executed on a virtual machine and controls execution of a plurality of functions executed as threads,
Computer processor,
Obtaining from the virtual machine the remaining amount of memory allocated to the virtual machine at the start of execution of a specific function;
The reference memory consumption for each specific function is extracted from the memory consumption table for each function that stores the reference memory consumption for each function executed in the past, and the extracted reference memory consumption is extracted. A memory consumption prediction value calculating step for calculating a memory consumption prediction value of the specific function from:
When the difference between the remaining amount of memory and the memory consumption prediction value is less than a predetermined threshold, causing the virtual machine to stop the thread of the specific function;
A control program to execute.

(Appendix 2)
When the difference between the remaining amount of the memory and the predicted memory consumption value is equal to or greater than the predetermined threshold, the data regarding the thread of the specific function including the remaining amount of the memory is being executed. Registering in the running thread table to store data about threads of
Obtaining from the virtual machine a second remaining amount of the memory that is the remaining amount of memory allocated to the virtual machine at the end of execution of the specific function;
Obtaining the remaining amount of the memory of the specific function from the executing thread table;
The net memory consumption, which is the difference between the second remaining amount of the memory and the remaining amount of the memory, is simultaneously executed with the specific function and the specific function specified from the executing thread table. An estimated memory consumption calculating step for calculating the estimated memory consumption for the specific function by dividing with other functions
Registering the estimated memory consumption for the specific function in the function-specific memory consumption table;
The control program according to appendix 1, for causing the processor to further execute

(Appendix 3)
The memory consumption predicted value calculation step includes:
Calculating an average value of the extracted approximate memory consumption;
Calculating a predetermined ratio of the average value of the absolute values of the differences between the extracted estimated memory consumption and the average value of the estimated memory consumption as a variance risk value;
Calculating the sum of the average value of the estimated memory consumption and the variance risk value as the memory consumption prediction value;
The control program according to appendix 1, including:

(Appendix 4)
The reference memory consumption calculation step includes:
Obtaining an average value of the estimated memory consumption of the specific function;
Obtaining an average value of the estimated memory consumption for each of the other functions that are specified from the executing thread table and are simultaneously executed with the specific function;
The net memory consumption is prorated by the average value of the standard memory consumption of the specific function and a predetermined ratio of the average value of the standard memory consumption of each of the other functions, and the specific function Calculating the estimated memory consumption of
The control program according to appendix 2, including

(Appendix 5)
The memory consumption predicted value calculation step includes:
Determining whether the reference memory consumption amount for the specific function has been extracted by a predetermined number of executions from a memory consumption table for each function that stores the reference memory consumption amount of each function executed in the past for each execution. Including
When the reference memory consumption amount cannot be extracted by the predetermined number of executions, the data regarding the thread of the specific function including the remaining amount of the memory is stored in the executing thread table storing data regarding the thread of the function being executed. The control program according to appendix 1, for further executing the step of registration.

(Appendix 6)
A control method included in a program executed on a virtual machine and executed by a computer having a control unit that controls execution of a plurality of functions executed as threads,
The control unit obtaining from the virtual machine the remaining amount of memory allocated to the virtual machine at the start of execution of a specific function;
The control unit extracts the reference memory consumption amount for the specific function from the memory consumption table for each function that stores the reference memory consumption amount of each function executed in the past for each execution. A predicted memory consumption value calculating step of calculating a predicted memory consumption value of the specific function from the estimated memory consumption;
When the difference between the remaining amount of memory and the predicted memory consumption is less than a predetermined threshold, the control unit causes the virtual machine to stop the thread of the specific function;
Control method.

(Appendix 7)
A control unit that controls execution of a plurality of functions that are included in a program executed on a virtual machine and executed as a thread;
The control unit is
Means for acquiring from the virtual machine the remaining amount of memory allocated to the virtual machine at the start of execution of a specific function;
The reference memory consumption for each specific function is extracted from the memory consumption table for each function that stores the reference memory consumption for each function executed in the past, and the extracted reference memory consumption is extracted. A memory consumption predicted value calculating means for calculating a memory consumption predicted value of the specific function from:
Means for causing the virtual machine to stop the thread of the specific function when the difference between the remaining amount of memory and the memory consumption predicted value is less than a predetermined threshold;
Having a computer.

It is a schematic diagram showing the relationship between OS and a process. It is a schematic diagram showing the relationship between a virtual machine and a thread. It is a schematic diagram for demonstrating the memory consumption of the function performed with a thread | sled. It is a program block diagram in embodiment of this invention. It is a figure which shows an example of the memory consumption table classified by function. It is a figure which shows an example of the executing thread table. It is a figure which shows an example of the average memory consumption table classified by function. It is a detailed diagram of the program configuration in the embodiment of the present invention. It is a figure which shows the outline | summary of the process in embodiment of this invention. It is a figure which shows the processing flow of the function start process of a memory management module. It is a figure which shows the processing flow of the memory consumption estimated value calculation process according to function. It is a figure which shows an example of a setting parameter. It is a figure which shows an example of the data extracted from the memory consumption table classified by function. It is a figure which shows the example of the 1st step of the process with respect to the executing thread table. It is a figure which shows the example of the 2nd step of the process with respect to the executing thread table. It is a figure which shows the example of the 3rd step of the process with respect to the executing thread table. It is a figure which shows the processing flow of the function end process of a memory management module. It is a figure which shows the processing flow of a standard memory consumption calculation process. It is a figure for demonstrating registration to the memory consumption table classified by function. It is a figure which shows the example of the 4th step of the process with respect to the executing thread table. It is a schematic diagram for demonstrating the method to produce | generate the measurement object program containing the call code to a memory management module. It is another program block diagram in embodiment of this invention. It is a functional block diagram of a computer.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 OS 10 Virtual machine 11 Server program 12 Measurement object program 13 Various libraries 14 Memory management module 141 Memory consumption table 142 according to function Running thread table 143 Average memory consumption table according to function

Claims (7)

A control program for executing a process of controlling the execution of a plurality of functions that is part of the program executing on the virtual machine to a processor of a computer,
The remaining amount of memory allocated to the virtual machine at the start of execution of the first function executed as a thread among the plurality of functions is determined from an executing thread table that stores data relating to the thread of the function being executed. A reading step;
Acquiring from the virtual machine the remaining amount of memory allocated to the virtual machine at the end of execution of the first function;
Calculating a first memory consumption that is a difference between a remaining amount of memory at the start of execution of the first function and a remaining amount of memory at the end of execution of the first function;
A first memory consumption table that stores a second memory consumption, which is a rough memory consumption of each function executed in the past, or the second memory of each function executed in the past Using the second memory consumption table that stores the average value of consumption, the first function and another function that is specified from the running thread table and that is simultaneously executed with the first function Obtaining an average value of the second memory consumption for
The calculated first memory consumption is calculated based on the average value of the second memory consumption of the first function and the second of the other functions being executed simultaneously with the first function. A first calculation step of calculating the second memory consumption amount for the first function by prorated based on an average value of the memory consumption amount;
A control program to execute. Obtaining a remaining amount of memory allocated to the virtual machine at the start of execution of a second function executed as a thread among the plurality of functions from the virtual machine;
The second memory consumption amount for the second function is extracted from the first memory consumption table, and a predicted value of the memory consumption of the second function is calculated from the second memory consumption amount. A second calculation step;
When the difference between the remaining amount of memory at the start of execution of the second function and the predicted value is less than a predetermined threshold, causing the virtual machine to stop the thread of the second function;
The control program according to claim 1, further causing the processor to execute. The second calculating step includes
Calculating an average value of the extracted second memory consumption amounts;
The average value of the difference between the extracted second memory consumption amount and the average value of the second memory consumption amount is calculated, and a variance risk value that is a value obtained by multiplying the average value by a predetermined ratio is calculated. A calculating step;
And calculating the predicted value is the sum of the variance risk value and the average value of the second memory consumption,
The control program according to claim 2 , including: The first calculating step includes:
The average value of the second memory consumption before Symbol first function, multiplied by a predetermined ratio to the average value of the second memory consumption of the first function and other functions that are performed at the same time in the value, the first pro rata memory consumption, the first function according to claim 1, wherein the control program, including the second steps for calculating the memory consumption. The second calculating step includes
From the first memory consumption table including said second step of determining whether the memory consumption can be extracted predetermined run several minutes for the second function,
Wherein when the second memory consumption can not be extracted predetermined run for a few minutes, the includes a remaining amount of the memory in the execution start of the second function, the data about the thread of the second function, the running thread The control program according to claim 2 for further executing the step of registering in the table. A control method that will be executed by a computer having a control unit for controlling the execution of a plurality of functions that is part of the program to be executed on the virtual machine,
The control unit stores the remaining amount of memory allocated to the virtual machine at the start of execution of the first function executed as a thread among the plurality of functions, and data related to the thread of the function being executed. Reading from the running thread table;
The control unit acquiring from the virtual machine the remaining amount of memory allocated to the virtual machine at the end of execution of the first function;
The control unit calculating a first memory consumption that is a difference between a remaining amount of memory at the start of execution of the first function and a remaining amount of memory at the end of execution of the first function; ,
The control unit stores a second memory consumption amount, which is a reference memory consumption amount of each function executed in the past, for each execution, or each function executed in the past. Using the second memory consumption table that stores the average value of the second memory consumption, the first function and the first function specified from the executing thread table are simultaneously executed. Obtaining an average value of the second memory consumption with respect to other functions that include:
The control unit uses the calculated first memory consumption amount as an average value of the second memory consumption amount for the first function and other functions executed simultaneously with the first function. Calculating the second memory consumption for the first function by allocating based on the average value of the second memory consumption of
Control method. A control unit for controlling the execution of a plurality of functions that is part of the program to be executed on the virtual machine,
The control unit is
The remaining amount of memory allocated to the virtual machine at the start of execution of the first function executed as a thread among the plurality of functions is determined from an executing thread table that stores data relating to the thread of the function being executed. Means for reading;
Means for obtaining from the virtual machine the remaining amount of memory allocated to the virtual machine at the end of execution of the first function;
Means for calculating a first memory consumption that is a difference between a remaining amount of memory at the start of execution of the first function and a remaining amount of memory at the end of execution of the first function;
A first memory consumption table that stores a second memory consumption, which is a rough memory consumption of each function executed in the past, or the second memory of each function executed in the past Using the second memory consumption table that stores the average value of consumption, the first function and another function that is specified from the running thread table and that is simultaneously executed with the first function And means for obtaining an average value of the second memory consumption,
The calculated first memory consumption is calculated based on the average value of the second memory consumption of the first function and the second of the other functions being executed simultaneously with the first function. Means for calculating the second memory consumption for the first function by apportioning based on an average value of the memory consumption;
Having a computer.

Images