Abstract:
A memory leak detecting method includes: producing an object which occupies an area on a first area of the memory; checking a presence of a pointer which points at the object separately so as to remove the object and to repeatedly carry out a process for counting up a counter value of the object separately upon the pointer not being present and being present; moving the area occupied by the object from the area on the first area of the memory to an area on the second area of the memory upon the counter value exceeding a first threshold; and moving the area occupied by the object from the area on the second area to the area on the first area and clearing the counter value of the object upon the object occupying the area on the second area being run.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is based upon and claims the benefit of priority of the prior Japanese Patent Application No. 2010-071056, filed on Mar. 25, 2010, the entire contents of which are incorporated herein by reference. 
       FIELD 
       [0002]    The application relates to an operation processing device and a method of detecting a memory leak. 
       BACKGROUND 
       [0003]    After an object which occupies an area to be accessed on a memory is produced and used, the object having been made unnecessary is erased as a general rule. An object once produced, however, can possibly remain without being erased to cause a memory leak for a reason that, e.g., a program writer has made an error in the control of allocating or releasing an area on the memory. If such a memory leak occurs, a usable memory area is limited. If memory leaks increase, the memory can possibly be exhausted possibly resulting in a problem of a system failure, etc. 
         [0004]    In a system in which a garbage collection function (GC) is implemented such as the Java (registered trademark) language, an object and a pointer pointing at the object are not managed by the program writer but are managed by the GC. Thus, even if the program writer makes an error in the control of allocating or releasing an area on the memory, that kind of memory leak can be prevented. If no pointer points at the object, the GC identifies the object as garbage and a target to be erased. 
         [0005]    In other words, the GC does not identify the object as a target to be erased while the pointer pointing at the object exists. Thus, under conditions in which the object and the pointer pointing at the object exist but nevertheless the object is never used again, the unnecessary object continues to remain in the memory. If such objects increase, the memory ends up being exhausted. That is a memory leak that occurs even to a system in which the GC is implemented. 
         [0006]    While a program writer can use a lot of application programming interfaces (API) at present as open usage of software has become widespread, he or she finds it difficult to understand in detail the inside of an API that he or she will use. Thus, an error in a method for using the API can possibly cause a memory leak of a type such that a pointer of an unnecessary object exists and the unnecessary object resultantly continues to remain. 
         [0007]    Some methods for detecting a memory leak, e.g., of the Java (registered trademark) language are known, such as Oracle JRockit Mission Control (Memory Leak Detector) or IBM HeapAnalyzer. 
         [0008]    The method of Oracle JRockit Mission Control (Memory Leak Detector) is, if instances of one and the same class increase a lot in a time unit, for notifying a user of a name of the class and objects as a candidate of a memory leak. 
         [0009]    Meanwhile, the method of IBM HeapAnalyzer is, if lots of instances of one and the same class remain on a memory at the end of the GC, provides a user with a name of the class and object information as a candidate of a memory leak. 
         [0010]    These methods for detecting a memory leak have following problems in: 
         [0011]    that the methods are unable to detect a small memory leak, e.g., just one leaking object; 
         [0012]    that the methods are unable to detect a memory leak that occurred in the past. In case of an application that periodically repeats a memory leak, no leak can be detected even if a tool is used when no memory leak occurs; and 
         [0013]    that lots of objects which remain on the memory do not necessarily cause a leak. An object programmed to be used at a certain time after being unused for a while can possibly exist. Thus, in order to identify whether a memory leak is present, it is necessary to observe information of the object for a certain period of time. 
         [0014]    Further, a method for recording entire information of access to all objects on every page of a memory so as to detect a memory leak at a frequency of the access is known, e.g., as disclosed in Japanese Unexamined Patent Application Publication No. 2009-26081. Observation of the entire access to all the objects, however, excessively loads the system operation. Further, if objects of different access frequencies are arranged on a same page, the method for recording the access on every page reduces accuracy of the leak detection. 
       SUMMARY 
       [0015]    According to an aspect of the embodiment, a method of detecting a memory leak includes: 
         [0016]    producing an object which occupies an area on a first area of the memory; 
         [0017]    checking a presence of a pointer which points at the object separately so as to remove the object and to repeatedly carry out a process for counting up a counter value of the object separately upon the pointer not being present and being present, respectively; 
         [0018]    moving the area occupied by the object from the area on the first area of the memory to an area on the second area of the memory upon the counter value exceeding a first threshold; 
         [0019]    moving the area occupied by the object from the area on the second area to the area on the first area and clearing the counter value of the object upon the object occupying the area on the second area being run; and 
         [0020]    announcing the object occupying the area on the second area upon the counter value exceeding a second threshold. 
         [0021]    The object and advantages of the embodiment will be realized and attained at least by the elements, features, and combinations particularly pointed out in the claims. 
         [0022]    It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the embodiment, as claimed. 
     
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         [0023]      FIG. 1  illustrates a configuration of an operation processing device; 
           [0024]      FIG. 2  is a flowchart illustrating a procedure to produce an object; 
           [0025]      FIG. 3  illustrates an object structure; 
           [0026]      FIG. 4  schematically illustrates a structure of stack trace data; 
           [0027]      FIG. 5  schematically illustrates areas A and B on a memory; 
           [0028]      FIG. 6  is a flowchart illustrating a procedure to remove an object; 
           [0029]      FIG. 7  schematically illustrates a move of an object; 
           [0030]      FIG. 8  illustrates a process for running an object being in the area B; 
           [0031]      FIG. 9  is a flowchart illustrating a process to be run upon an application program accessing an object being in the area B; 
           [0032]      FIG. 10  is a flowchart illustrating a handling process; 
           [0033]      FIG. 11  is a flowchart illustrating a main routine of a GC process; 
           [0034]      FIG. 12  is a flowchart illustrating a process for moving an object from the area B to the area A at a operation S 42  in  FIG. 11 ; 
           [0035]      FIG. 13  is a flowchart illustrating a process for removing an object or moving the object from the area A to the area B at a operation S 43  in  FIG. 11 ; 
           [0036]      FIG. 14  is a flowchart illustrating a process for outputting data of an object possibly causing a memory leak at a operation S 44  in  FIG. 11 ; 
           [0037]      FIG. 15  illustrates exemplary data of an object output at a operation S 443  in  FIG. 14  and possibly causing a memory leak; 
           [0038]      FIG. 16  illustrates a modification of a data output process of an object which highly possibly causes a memory leak; and 
           [0039]      FIG. 17  is a flowchart illustrating a modification of a process for moving an object from the area B to the area A. 
       
    
    
     DESCRIPTION OF EMBODIMENTS 
       [0040]    According to a method of detecting a memory leak disclosed here by the application, the processor carries out the following (1)-(5) processes: 
         [0041]    (1) to produce an object that occupies an area on a first area of the memory; 
         [0042]    (2) to repeat a following process. In the process, every object is examined for existence of a pointer that points at the object and an object with no pointer is removed. Further, in the process as well, a counter value of every object with a pointer is individually counted; 
         [0043]    (3) to move an area occupied by an object for which the counted value exceeds a first threshold from the area on the first area of the memory to an area on a second area of the memory; 
         [0044]    (4) to move, upon an object that occupies an area on the second area being used, the area occupied by the object to an area on the first area, and to clear the counter value of the object; and 
         [0045]    (5) to announce one of objects which occupy areas on the second area, for which the counter value exceeds a second threshold. 
         [0046]    Incidentally, the memory to be dealt with by the method of detecting a memory leak disclosed by the application is a memory to be a target in which an object occupies an area, and is not limited to a main memory. If, e.g., the object counts an area in a storage portion of an HDD (hard disk drive) or something as a target to be occupied, the storage portion of the HDD or something is included in the memory of the application. 
         [0047]    An embodiment of the application will be explained below. 
         [0048]      FIG. 1  illustrates a configuration of an operation processing device of an embodiment. 
         [0049]    A hardware configuration is illustrated in a lowest portion of  FIG. 1 , where a personal computer (PC) of an ordinary configuration is assumed. A processor  21 , a memory  22 , an input device  23  and an output device  24  are included as hardware  20 . The processor  21  runs a program. The memory  22  is in charge of data storage, and is accessed (data writing or reading) upon the program being run. The memory  22  of the embodiment is a main memory in which the program to be run by the processor  21  is stored. The memory of the application, however, need not be limited to a main memory, and can be a storage device such as an HDD (hard disk drive). 
         [0050]    Further, the input device  23  includes an input device which accepts a user&#39;s operation through a keyboard, a mouse, etc., and a receiving device, etc., which accepts instructions from the outside of the operation processing device  10  through a communication line, etc. 
         [0051]    Further, the output device  24  includes an image display device which displays an image for a user of the operation processing device  10 , a speaker which delivers sound to the user, and a transmitting device, etc., which sends information to the outside of the operation processing device  10  through a communication line, etc. 
         [0052]    An operating system (OS)  30  runs on the hardware  20 , and a process  40  is run as software as controlled by the OS. The OS  30  is in charge of the process  40 . Controls of the embodiment to be focused on as to the embodiment are “to call a handling process” and “to change access protection”, which will be described later in detail. 
         [0053]    The process  40  has a communication function  41 , a handling process running function  42 , an application running function  43 , a GC running function  44  and a memory managing function  45 . Further, the process  40  manages stack trace data  46  on the memory  22  and an accessed address list  47 . 
         [0054]    The operation processing device  10  has various kinds of application programs as well as the hardware  20 , the OS  30  and the process  40  described here. 
         [0055]    The communication function  41  which forms the process  40  is a thread in charge of communication between the process  40  and another process or the input device  23 . 
         [0056]    The handling process running function  42  is in charge of running a handling process when an area B being prohibited from being accessed is illegally accessed, which will be described later in detail. 
         [0057]    The application running function  43  is a thread to be activated when various applications are run. 
         [0058]    The GC running function  44  repeatedly runs the GC. The GC running function  44  has a counter of GC running  441 . The counter  441  counts the number of times of GC running for every object, which will be described later in detail. 
         [0059]    The memory managing function  45  sets areas A and B on the memory  22  on the hardware  20  and manages the areas A and B. How to use the areas A and B will be described later. The stack trace data  46  and the accessed address list  47  will be described later as well. 
         [0060]      FIG. 2  is a flowchart illustrating a procedure to produce an object. 
         [0061]    If an application program is run and the application program instructs that an object be produced, the application running function  43  carries out a process according to the flowchart illustrated in  FIG. 2 . 
         [0062]      FIG. 3  illustrates an object structure. 
         [0063]    The object has a data portion to or from which data is written or read and a header portion in which the number of times of GC running and a pointer to the stack trace data are recorded. 
         [0064]      FIG. 4  schematically illustrates a structure of the stack trace data. 
         [0065]    Method data representing methods is stacked here in order of a calling method to a called method. Each of the method data is formed by a name of a method and a numerical value (line number) that specifies a line on which the method is written in the program. A method is specified by the name and the line number recorded there. 
         [0066]    Method data  1 ,  2 , . . . , N is stacked here, and the method data  1  stacked on the top is the method that has produced the object. The stack trace data further has a “reference count”. The “reference count” is a counter provided for a case in which objects produced multiple times have the same stack trace data, so as to avoid a plurality of the same stack trace data from being made. A positive number n recorded on the “reference count” represents that that one piece of stack trace data is common to n-objects. 
         [0067]      FIG. 5  schematically illustrates the areas A and B on the memory. 
         [0068]    An object is produced so as to occupy a part of the area A. The area B is not used when an area is produced. An area occupied by an object once produced can possibly be moved, though, in such a way that the object occupies an area in the area B, which will be explained later. 
         [0069]    The flowchart illustrated in  FIG. 2  will be explained on the basis of the explanation with reference to  FIGS. 3-5 . 
         [0070]    An object is produced (operation S 11 ). In order that the object is produced, as described above, an area in the area A is allotted to the object as an area to and from which data is written and read. The object has the header portion illustrated in  FIG. 3 , and the number of times of GC running set in the header portion is set to an initial value (zero in this case) (operation S 12 ). 
         [0071]    The calling relations (see  FIG. 4 ) of the method which produced the object are obtained (operation S 13 ), and whether stack trace data which is substantially the same as the stack trace data to be referred to by the object produced exists is identified (operation S 14 ). If no such stack trace data exists, produce stack trace data for the object produced (operation S 15 ), set the reference count of the stack trace data to ‘1’ (operation S 16 ), and set the address of the stack trace data is set to the header of the object produced (operation S 18 ). 
         [0072]    If substantially the same stack trace data which already exists is identified at the operation S 14 , add ‘1’ to the reference count of the same stack trace data (operation S 17 ), and set the address of the same stack trace data to the header of the object (operation S 18 ). 
         [0073]      FIG. 6  is a flowchart illustrating a procedure to remove an object. 
         [0074]      FIG. 6  is a flowchart of a case in which the GC removes the object. That is, if no pointer that points at the object remains, the GC running function  44  (see  FIG. 1 ) carries out a process according to the flowchart in  FIG. 6 . 
         [0075]    In this case, ‘1’ is subtracted from the reference count (see  FIG. 4 ) of the stack trace data that the pointer of the stack trace data recorded in the header of the object to be removed as determined points at (operation S 21 ). Identification of whether the reference count is zero or one or more after ‘1’ is subtracted (operation S 22 ). If the reference count is zero, the stack trace data (operation S 23 ) is removed, and the object itself to be removed as instructed (operation S 24 ) is also removed. If the reference count of the stack trace data being one or more is identified at the operation S 22 , the object to be removed as instructed while leaving the stack trace data (operation S 24 ) is removed. 
         [0076]      FIG. 7  schematically illustrates a move of an object. 
         [0077]    In order that an object is produced, as described above, an area occupied by the object is set in the area A. Here, it is called that the object is put in the area A. An object having experienced the GC more than a certain number of times owing to GC repetition described later is changed in such a way that the occupied area is in the area B. Here, it is called that the object is moved to the area B. 
         [0078]    If the object having moved to the area B is accessed, the object is moved back to the area A. 
         [0079]      FIG. 8  illustrates a process for running the object which is in the area B. 
         [0080]    Examples of a method employed here of detecting an access to the object is to use an OS-provided function for changing memory access protection. The OS-provided function for changing memory access protection is mprotect of Solaris or Linux, or VirtualProtect of Windows (registered trademark), etc. 
         [0081]    Both reading and writing operations for access protection in the area B are prohibited. Further, a process for handling an illegal access is set. 
         [0082]    If an object being in the area B is accessed in the above conditions, the OS detects an illegal access and the handling process having been set is run. According to the handling process, the access protection in the area B is changed to what allows both reading and writing operations, and the access to the object is done. Further, the accessed address is added to the list. The access protection in the area B returns to what prohibits both reading and writing operations. After the handling process ends here, the process returns to the former process. 
         [0083]    In a next GC, an object including the address included in the list is moved to the area A and the number of times of GC running of the object is changed to the initial value. 
         [0084]    The process for running an object being in the area B will be explained in accordance with a flowchart. 
         [0085]      FIG. 9  is a flowchart illustrating a process to be run upon an application program accessing an object being in the area B. 
         [0086]    If an application program accesses an object being in the area B (operation S 31 ), an illegal access occurs (operation S 32 ) and a handling process is carried out (operation S 33 ). After the handling process ends, the process according to the application program continues (operation S 34 ). 
         [0087]      FIG. 10  is a flowchart illustrating the handling process. 
         [0088]    According to the handling process at the operation S 33  in  FIG. 9 , the access protection in the area B is changed to what allows both reading and writing operations (operation S 331 ), and a reading or writing operation from or to the object is carried out (operation S 332 ). Further, the address in the area B accessed this time is added to the list (see  FIG. 8 ) (operation S 333 ), and the access protection in the area B is changed back to what prohibits both reading and writing operations (operation S 334 ). 
         [0089]    According to the embodiment, the object is not moved from the area B to the area A at this point of time in the handling process, but is moved when a next GC process is carried out. 
         [0090]      FIG. 11  is a flowchart illustrating a main routine of the GC process. 
         [0091]    The GC running function  44  illustrated in  FIG. 1  carries out the GC process explained below. The GC process can be carried out at regular intervals, or can be randomly carried out, e.g., at a timing of a bit dropped rate of operation of the processor  21  (see  FIG. 1 ). 
         [0092]    According to the GC process illustrated in  FIG. 11 , at first, the access to the area B having been prohibited is released (operation S 41 ). That is, the memory protection attribute of the area B is changed to what allows both writing and reading operations. 
         [0093]    The process for moving the object from the area B to the area A is carried out (operation S 42 ). That is, the list (see  FIG. 8 ) in which addresses accessed in the area B are recorded is here referred to, and an object including one of the addresses recorded in the list is moved from the area B to the area A. 
         [0094]    Further, an unnecessary object is removed, and a process for moving the object with a lot of number of GC running in the area A is moved to the area B (operation S 43 ). Further, a process for outputting data of an object being in the area B possibly causing a memory leak is carried out (operation S 44 ). The access to the area B is prohibited again (operation S 45 ). 
         [0095]      FIG. 12  is a flowchart illustrating the process for moving the object from the area B to the area A at the operation S 42  in  FIG. 11 . 
         [0096]    In  FIG. 12 , while the objects being in the area B are each focused on one by one, a following process is carried out for the focused-on object (operation S 421 ). 
         [0097]    An identification is made whether the focused-on object includes one of the addresses recorded in the list (see  FIG. 8 ) of the accessed addresses (operation S 422 ). If the focused-on object has no relation to the addresses in the list, the process returns to operation S 421  and focus on the next object. 
         [0098]    Meanwhile, if the focused-on object includes one of the addresses in the list (operation S 422 ), the number of times of GC running to zero (operation S 423 ) is cleared and the focused-on object from the area B to the area A (operation S 424 ) is moved. The process returns to the operation S 421  and focus on the next object. 
         [0099]    If the process is completed for all the objects being in the area B, the routine is exited (operation S 421 ). 
         [0100]      FIG. 13  is a flowchart illustrating a process for removing an object or moving the object from the area A to the area B at the operation S 43  in  FIG. 11 . 
         [0101]    In  FIG. 13 , the objects being in any one of the areas A and B are each focused on one by one, and a following process is carried out for the focused-on object (operation S 431 ). 
         [0102]    An identification is made whether a pointer pointing at the focused-on object exists (operation S 432 ). If no pointer points at the object, remove the object from the memory (operation S 433 ). The process returns to the operation S 431  so as to focus on the next object, and carry out a similar process for the new focused-on object. The process for searching for an existing pointer and for removing an object with no pointer at the operations S 432  and S 433  is a basic process known as garbage collection (GC), and its detailed explanation is omitted. 
         [0103]    If a pointer pointing at the focused-on object is identified as existing at the operation S 432 , ‘1’ is added to the number of times of GC running (see  FIG. 3 ) of the focused-on object (operation S 434 ). An identification is made whether the object is in the area A or in the area B (operation S 435 ). If the object is not in the area A (but in the area B), the process returns to the operation S 431 . If the object is in the area A, the process proceeds to operation S 436  so as to identify whether the number of times of GC running of the object has exceeded a threshold (operation S 436 ). The threshold is an example of the first threshold of the application. If the number of times of GC running of the object has not exceeded the threshold yet, the process returns to the operation S 431 . If the number of times of GC running of the object has exceeded the threshold, the process returns to the operation S 431  after the object is moved to the area B (operation S 437 ). 
         [0104]    If the process is completed for all the objects being in the areas A and B, the routine is exited (operation S 431 ). 
         [0105]      FIG. 14  is a flowchart illustrating the process for outputting data of an object possibly causing a memory leak at the operation S 44  in  FIG. 11 . 
         [0106]    In  FIG. 14 , while the objects being in the area B are each focused on one by one, a following process is carried out for the focused-on object (operation S 441 ). 
         [0107]    A check of the number of times of GC running of the focused-on object being in the area B is made, and an identification is made whether the threshold (used at the operation S 436  in  FIG. 13 ) subtracted from the number of times of GC running is greater than a fixed value (operation S 442 ). The sum of the “threshold” and the “fixed value” is an example of the second threshold of the application. 
         [0108]    If the threshold subtracted from the number of times of GC running is smaller than the fixed value, the process returns to the operation S 441  so as to carry out a similar process focusing on the next object being in the area B. 
         [0109]    If the threshold subtracted from the number of times of GC running is greater than the fixed value, output the data of the object (operation S 443 ). The process returns to the operation S 441 . 
         [0110]    If the process is completed for all the objects being in the area B, the routine is exited. 
         [0111]      FIG. 15  illustrates exemplary data of the object output at the operation S 443  in  FIG. 14  and possibly causing a memory leak. 
         [0112]    As a form of data output, data illustrated in  FIG. 15  is displayed here on a screen of the image display device which forms the output device  24  of the operation processing device  10  illustrated in  FIG. 1 . 
         [0113]    The first line illustrated in  FIG. 15  indicates an object that has never been accessed while experiencing the GC process 1000 times. The second and following lines indicate history of production of the object (see  FIG. 4 ). 
         [0114]    Modifications of the embodiment will be explained below. Matters different from the embodiment only will be explained for each of the modifications. 
         [0115]    According to the embodiment described above, the data output process is carried out in course of the GC process (see  FIGS. 11 and 14 ). The data output process can be carried out as explained below in addition to, or instead of, being carried out in course of the GC process. 
         [0116]      FIG. 16  illustrates a modification of the data output process of an object highly possibly causing a memory leak. 
         [0117]      FIG. 16  illustrates that the process  40  illustrated in  FIG. 1 , upon the communication function  41  in the process  40  being requested by another process to send data of an object causing a leak, sends the data of the object causing a leak back to the process which made the request.  FIG. 16  illustrates that the process  40 , upon being requested by a user of the operation processing device  10  through an operation on the input device  23  to output data of an object causing a leak, outputs the data of the object causing a leak onto the screen or a file. 
         [0118]    As described above, the process  40  can be configured, upon being requested to send data of an object causing a leak, to carry out a process corresponding to  FIG. 14  and to output the data. 
         [0119]    If no data output process is carried out in the GC process, the process of the operation  44  in  FIG. 11 , e.g., the process illustrated in  FIG. 14  is excluded from the GC process. 
         [0120]      FIG. 17  is a flowchart illustrating a modification of a process for moving an object from the area B to the area A. 
         [0121]      FIG. 17  illustrates a handling process to be employed instead of the handling process illustrated in  FIG. 10  of the above embodiment. 
         [0122]    If the handling process illustrated in  FIG. 17  is employed for the operation S 33  in  FIG. 9 , the handling process of  FIG. 10  and the process of the operation S 42  in the GC process illustrated in  FIG. 11  may be omitted, e.g., the process illustrated in  FIG. 12 . Further, the list illustrated in  FIG. 8  may also not be made. 
         [0123]    According to the handling process illustrated in  FIG. 17 , the access protection in the area B is changed to what allows both reading and writing operations (operation S 335 ). The object being in the area B accessed at the operation S 31  in  FIG. 12  is moved to the area A (operation S 336 ), and the access protection in the area B is changed to what prohibits both reading and writing operations (operation S 337 ). Further, the number of times of GC running of the object that has been moved to the area A is cleared to zero (operation S 338 ), and a reading or writing operation from or to the object is carried out (operation S 339 ). 
         [0124]    Although being carried out by the GC running function  44  according to the embodiment described above, the process for moving the object from the area B to the area A can be carried out by the handling process running function  42  as illustrated in  FIG. 17 . If the moving process is carried out by the handling process running function  42 , the process for making the list illustrated in  FIG. 8 , etc., is unnecessary, so that the process can be simplified. In this case, however, the moving process is carried out in the handling process in course of an application program being run, e.g., an exceptional process of a raised priority, resulting in an increase in the processing load for that. Meanwhile, the GC process can be carried out at a time when the operation processing device  10  can afford to run applications, so as to prevent the load from increasing. 
         [0125]    For any of the embodiment and the modifications, however, it is enough to observe objects being only in the area B and a memory leak can be detected with a light load. 
         [0126]    All examples and conditional language recited herein are intended for pedagogical purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Although the embodiment(s) of the present invention(s) has(have) been described in detail, it should be understood that the various changes, substitutions, and alterations could be made hereto without departing from the spirit and scope of the invention.