Field of the Invention
The present invention relates to a method of ascertaining the cause of memory consumption in a program, and a computer system and computer program for the same.
Description of Related Art
In order to tune up the performance of a program, a user may get an execution profile of memory consumption by this program. In this case, the user may often want to identify what in the program causes certain memory consumption. This is because if the cause can be identified, it will be easy for the user to focus on the limited part of the original program logic as the cause of the memory consumption in order to alter it for reducing the memory consumption that poses a performance problem.
When the user employs a conventional execution profile technique using a profiler, for example, it is easy to trace down a method, which has come to create an object whose memory consumption would be problematic at a certain point during program execution, and source methods that called the method directly or indirectly, which end up with the root (very beginning) method call. For example, in the case of Java™, the user uses a profiler called hprof that comes with Java™ 2 SE 6.0 to record an object ID in a location where the object is created in the program and a method call stack up to the location. The record enables the user to get the ID of the object likely to be problematic and the call stack of methods up to the creation of the object.
However, in the above conventional execution profile technique, the user cannot understand why the problematic object stays in the memory during program execution and how the object has become problematic. In other words, the user cannot derive, from the record, what caused the object to become problematic, at least partly because the user has registered the object in a table likely to continue to stay in the memory.
In a technique disclosed in Japanese Application Publication No. 2008-134709, a request ID on an object created during processing the request to a server and a method call stack up to the creation are recorded. When there is an object staying in a memory as long as the request processing is completed, the object is suspected of causing a memory leak. The object is presented together with the method call stack recorded up to the creation of the object.
Bond, M. D., McKinley, K. S., “Probabilistic Calling Context,” in Proceedings of OOPSLA 2007, the 22nd Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications, Montreal, Quebec, Canada, pp. 97-112, Oct. 21-25, 2007 teaches a technique called probabilistic calling context (PCC). PCC is known as a technique for holding down the overhead at the time of execution profile acquisition to a small percentage. PCC aims at verifying that two calling contexts are identical with a high probability.
In the conventional execution profile technique, the user cannot understand why the object whose memory consumption is problematic at a certain point during program execution stays in the memory during program execution and how the object has become problematic. Therefore, it is desired to have a method of holding information for identifying why the object has become problematic and presenting the information to the user.