Vijay Krishna's Notes http://vijaykrishna.posterous.com Most of my notes as a student of computer software and everything around it. posterous.com Wed, 25 Jan 2012 11:48:00 -0800 Beware of the Hound ... woof! http://vijaykrishna.posterous.com/beware-of-the-hound-woof http://vijaykrishna.posterous.com/beware-of-the-hound-woof

This was one of the more interesting papers i read last weekend. Here is the link: http://dl.acm.org/citation.cfm?id=1542521. And here is what i understood of it:

This paper addresses the problem of memory leaks with a radically new approach compared to the papers that we have read so far about Memory Leaks. Its approach is data centric instead of code centric as was the case with Sleigh and SWAT. We have read one other data centric approach with Cork, however Cork was addressing a more Java specific issue in the world of memory leaks. This paper presents Hound, which is looking at resolving memory leaks in C and C++. And it does so in the most fundamental manner possible, i.e. by revamping the strategy of allocating or rather organizing memory for objects in the heap. This is a very low level approach, which for the purposes of this paper has been done largely in the Linux environment. The abstract idea presented here seems portable, however the authors would have done well if they had highlighted how easy or difficult would porting such an approach to other environments like Java and Windows be. As a side note, I could not help but wonder how the C language could be referred to, in a paper which discusses objects?

The allocation of memory is done using segregation of objects first on the basis of allocation sites, and then on the basis of object age, which helps in measuring staleness. Segregation on the basis of allocation sites follows the logic that objects allocated in the same site tend to follow the same behavior. Which leads to the notion that a leaking site is the source of leaking objects and hence makes sense to group them together. This is aligned with the ordering logic in SWAT which too uses the number of objects for a given allocation site while reporting leaks to the user. Each allocation site is associated with its own heap. In order to reduce memory overhead, a site is assigned a new heap only after the number of objects in each of its previous heaps reach a threshold value, i.e are full. The object count is kept track of by inserting a hash of the allocation site in each of its objects. The count is incremented upon an allocation and reduced upon memory frees. While objects with the same allocation site exhibit similar behavior, it is often not the case. In order to avoid anomalous cases where hot and old objects are generated from the same allocation site, segregation on the age of the objects is also done. For this, two lists: active and inactive are maintained within the aging queue, which holds all the filled pages. The pages in the active list contain objects in a FIFO order which are accessed more recently and old objects are stored in the inactive list which stores it in the least recently used order. This separation of active and inactive lists is done to reduce the performance overhead which will occur due to increasing number of page faults when objects are accessed from pages in the age queue. Such page faults occur because pages containing old objects are protected. Thus the pages in the active list are left unprotected. Age for objects are calculated using (current time - protection time). When an object is accessed from a page in the inactive list, then the page is shifted to the head of the active list and the age for all the objects in that page is set to 0, and the page is set to be unprotected. My only concern with such an approach where the ages of all the objects are handled together is that, just because one among them was accessed the rest might not necessarily be used again. This shows the importance of limiting the number of objects in a given page.

Now the shifting from inactive to active is done on a need-to-need basis, and hence can be viewed as lazy in approach. However, Hound maintains a target size for the inactive list, which is approached gradually in order to reduce the sudden increase in minor page faults that might result from a large shift of pages from the unprotected active list to the protected inactive list. If the inactive list's size is significantly smaller than the target size, Hound moves as many as 8 pages from the active list to the inactive list. This is far more aggressive than the policy it adopts while shifting pages from the the inactive list. This exhibits the conservative nature of the approach that results in zero false positives, but also leads to an increase in false negatives.

In this particular memory management policy, the objects of a page are not reclaimed till the live count of the page is zero. Thus, even if a single live object is present the page will not be reclaimed. This induces a severe memory overhead, which can be resolved by merging pages with 50% or lesser live count on top of each other in physical memory while keeping them separate in virtual memory. As explained by the paper this is done in a cost effective manner.

Due to the segregation strategies, while the staleness analysis is done at a page level, results are reported at a per allocation site basis. The sites themselves are ranked based on the number of objects from an allocation site and the summation of the drag of all the objects at that site, which is similar to the ordering approach that was taken up in SWAT.

In terms of performance Hound results in slightly higher overheads both for memory and runtime. While is true for most techniques which deal with memory leaks, they are still far more portable than Hound as they address this problem at a higher level of abstraction. Hound on the other hand addresses this problem at a much more low level, and thus one would expect little or no over head of any nature. On a different note, comparing the accuracy of staleness computation with that of SWAT is of little value in my opinion. Like the paper rightly points out, Hound and SWAT have different limitations and both do well within those limitations, as pointed out by the results. It is like comparing apples and oranges: both are fruit, but are vastly different in terms of taste and the nutrition they provide. It would have been better to compare Hound with a more data centric approach such as Cork.

Nonetheless, the comparison gave me an interesting idea. Since, Hound looks to underestimate staleness and SWAT looks at overestimating it, it won't be a bad idea to look at the overlap of the results produced by them. The overlap might give you a 100% accurate listing of the memory leaks. Having said that, between the two, I would choose SWAT, simply because overestimating is better because it might point to certain design flaws in the memory management of the program under test. A conservative approach, like Hound, will never be able to do this.

Permalink | Leave a comment  »

]]>
http://files.posterous.com/user_profile_pics/1369599/pic.jpeg http://posterous.com/users/hcGXxsTkwP6SS Vijay Krishna Palepu vpalepu Vijay Krishna Palepu