+ All Categories
Home > Documents > LeakChaser: Helping Programmers Narrow Down Causes of Memory Leaks Guoqing Xu, Michael D. Bond, Feng...

LeakChaser: Helping Programmers Narrow Down Causes of Memory Leaks Guoqing Xu, Michael D. Bond, Feng...

Date post: 21-Dec-2015
Category:
View: 219 times
Download: 0 times
Share this document with a friend
Popular Tags:
13
LeakChaser: Helping Programmers Narrow Down Causes of Memory Leaks Guoqing Xu, Michael D. Bond, Feng Qin, Atanas Rountev Ohio State University
Transcript

LeakChaser: Helping Programmers Narrow Down Causes of Memory Leaks

Guoqing Xu, Michael D. Bond, Feng Qin, Atanas Rountev

Ohio State University

Java Memory Leaks• Objects are reachable, but not used

– Kept by unnecessary references • Existing memory leak detection techniques

– Unaware of program semantics: track arbitrary objects– No focus: profiling the whole execution--- real causes

buried in a sea of likely problems• Developer insight is necessary in leak detection—a

three-tier approach to exploit such insight Tier L Tier M Tier H

Manual

LeakChaser

Manual

LeakChaser

Manual

LeakChaser

Exploiting Developer Insight

3

• Heap assertions– GC Assertions: A reachability-based assertion

framework [Aftandilian-PLDI’09]– E.g., assertOwns(a, b)– Works only for objects that have low-level structural

reachability relationships• Lifetime invariants exist in large-scale apps

– Lifetimes for certain objects are strongly correlated Screen s = new Screen(…);

Configuration c = new Configuration();/*s and c should always be created together and eventually die together */

Tier L: Low-Level Liveness Assertions• An assertion framework to specify lifetime

relationships– assertDiesBefore(c, s) // s: Screen, c: Configuration– assertDiesBeforeAlloc(s, s)

• Our framework vs GC Assertions– Can be used to assert objects that have high-level

semantic relationships (instead of low-level structural relationships)

4

High-Level Events: Transactions• Frequently-executed code regions

– Likely to contain memory leaks– Inspired by EJB transactions

• Allow programmers to specify transactions

5

ResultSet runQuery(String query){ Connection c = getConnection(…); Statement s = c.createStmt(); ResultSet r = s.executeQuery(query); return r;} …… …Heap

Transaction Specification

• Transaction– A user-specified spatial boundary– A transaction identifier object that is correlated with

the livenss of this region: temporal boundary6

ResultSet runQuery(String query){ transaction { Connection c = getConnection(…); Statement s = c.createStmt(); ResultSet r = s.executeQuery(query); } return r;}

(query)

Tier M: Checking Transaction Properties

• Semanticsfor each object o created in this transaction do assertDiesBefore (o, query)

• Share regionfor each object o created in this transaction if o is not created in share do assertDiesBefore (o, query)

7

ResultSet runQuery(String query){ transaction (query) { Connection c = getConnection(…); share{ Statement s = c.createStmt(); globalMap.cache(s); } ResultSet r = s.executeQuery(query); } return r;}

Programmers do not need to understand implementation details to use low-level assertions

Tier H: Inferring Transaction Properties• Minimum requirement

for user involvement– Specify a transaction– Tell LeakChaser it runs in

the inference mode• Semantics

for each o created in this transactionif assertDiesBefore

(o, query) = false startTrackStaleness(o) if(o.staleness >= S) reportLeak();8

ResultSet runQuery(String query){ transaction (query ) { Connection c = getConnection(…); Statement s = c.createStmt(); globalMap.cache(s); ResultSet r = s.executeQuery(query); } return r;}

, INFER

Programmers let LeakChaser do most of the work

Three-Tier Approach• Tier H, Tier M, and Tier L

– Decreasing levels of abstraction– More knowledge required for diagnosis– Increased precision

• LeakChaser: an iterative diagnosis process– Start Tier H with little knowledge– Gradually explore leaky behaviors to locate the root

cause

9

Case Studies• Six case studies on real-world applications

– Eclipse diff (bug #115789)– SPECJbb 2000: LeakChaser found a memory problem

never reported before– Eclipse editor (bug #139465): quickly concluded that

this was not a bug– Eclipse WTP (bug #155898): found the cause for this

bug that was reported three years ago and is still open– MySQL leak– Mckoi leak: first time found that a leaking thread is the

root cause• The ability of diagnosing problems for a large

system at its client10

Implementation• Jikes RVM

– Works for both baseline and optimizing compilers– Works for all non-generational tracing GCs

• Overhead on FastAdaptiveImmix (average)– Infrastructure: 10% on time, less than 10% on space – Transactions: 2.3X slowdown for 1088377 transactions

11

Conclusions• A three-tier approach for semantics-aware leak

detection• An implementation in Jikes RVM• The transaction constructs can be easily

incorporated into the Java language to help memory problem diagnosis

• LeakChaser is available for download– http://jikesrvm.org/Research+Archive

12

Thank you

13


Recommended