188宝金博页面版

A Dynamic Analysis to Support Object-Sharing CodeRefactoringsGirish Maskeri Rama∗Infosys Limitedgirish_rama@infosys.comRaghavan KomondoorIndian Institute of Science, Bangaloreraghavan@csa.iisc.ernet.inABSTRACTCreation of large numbers of co-existing long-lived isomor-phic objects increases the memory footprint of applicationssignif i cantly. In this paper we propose a dynamic-analysisbased approach that detects allocation sites that create largenumbers of long-lived isomorphic objects, estimates quan-titatively the memory savings to be obtained by sharingisomorphic objects created at these sites, and also checkswhether certain necessary conditions for safely employingobject sharing hold. We have implemented our approach asa tool, and have conducted experiments on several real-lifeJava benchmarks. The results from our experiments indicatethat in real benchmarks a signif i cant amount of heap mem-ory, ranging up to 37% in some benchmarks, can be saved byemploying object sharing. We have also validated the pre-cision of estimates from our tool by comparing these withactual savings obtained upon introducing object-sharing atselected sites in the real benchmarks.Categories and Subject DescriptorsD.2.7 [Software Engineering]: Distribution, Maintenance,and Enhancement; D.3.4 [Programming Languages]: Pro-cessorsKeywordsMemory optimization; object caching1. INTRODUCTIONThe advent of large system memories has not vetted theappetite for memory optimization tools for software. Forinstance, various researchers have noted [15, 16, 25, 24] thatsoftware commonly consumes unexpectedly high amountsof memory, frequently due to programming idioms that areused to make software more reliable, maintainable and un-derstandable. In the case of modern object-oriented systems∗ Currently pursuing part-time PhD in Indian Institute ofScience, Bangalore.Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor prof i t or commercial advantage and that copies bear this notice and the full citationon the f i rst page. Copyrights for components of this work owned by others than theauthor(s) must be honored. Abstracting with credit is permitted. To copy otherwise, orrepublish, to post on servers or to redistribute to lists, requires prior specif i c permissionand/or a fee. Request permissions from permissions@acm.org.ASE’14, September 15-19, 2014, Vasteras, Sweden.Copyright is held by the owner/author(s). Publication rights licensed to ACM.ACM 978-1-4503-3013-8/14/09 ...$15.00.http://dx.doi.org/10.1145/2642937.2642992 .public CommonFont getFontProps () {. . .CommonFont commonFont =new CommonFont(fontFamily , fontSelectionStrategy ,fontStretch , fontStyle , fontVariant ,fontWeight , fontSize , fontSizeAdjust ) ;return commonFont ;}Listing 1: Creation of isomorphic objectsthis problem is partly due creation of large numbers of co-existing isomorphic objects. Intuitively, two objects are iso-morphic if they are of the same type, have identical values incorresponding primitive f i elds, and are such that correspond-ing reference f i elds themselves point to isomorphic objects.In other words, the portions of memory rooted at the twoobjects are isomorphic shape-wise as well as values-wise.1.1 MotivationTo illustrate this problem consider the example code inListing 1, adapted from the real program Apache FOP. Thiscode has been substantially simplif i ed for ease of presenta-tion. The getFontProps method in the code is used to cre-ate a CommonFont object (to encode display properties) foreach FO (Formatting Objects) node in the input FO docu-ment. Each CommonFont object (which we simply call fontobject from here on) occupies 64 bytes in memory. For largedocuments the number of such font objects created is verylarge. However, in practice, because the f i elds of the Com-monFont class can take on only a small number of distinctvalues, e.g., Arial or TimesRoman for fontFamily and 10ptor 12pt for fontSize, many of the font objects created areisomorphic to each other. For instance, with a 104-page realinput document that we supplied as input, although the pro-gram created 9079 font objects, 8943 (i.e., 98.5%) of theseobjects belonged to only four distinct equivalence classes byisomorphism. Furthermore, all font objects are long lived(i.e., are live nearly until the end of execution of the pro-gram). A signif i cant reduction in heap usage can thereforebe achieved if the code is refactored to de-duplicate or sharecommon font objects whenever possible instead of alwayscreating distinct but possibly isomorphic objects. Such arefactoring, which employs a cache to keep track of objectscreated so far and to share them, is shown in Listing 2. Wehave elided the equals and hashCode methods of the Com-monFont class from the listing, which ensure that a cache713