Dai et al. / J Zhejiang Univ-Sci C (Comput & Electron) 1 Journal of Zhejiang University-SCIENCE C (Computers & Electronics) ISSN 1869-1951 (Print); ISSN 1869-196X (Online) www.zju.edu.cn/jzus; www.springerlink.com E-mail: [email protected] Automatic Recovery from Resource Exhaustion Exceptions by Collecting Leaked Resources∗ Zi-ying DAIy1, Xiao-guang MAOyz1,2, Li-qian CHEN1, Yan LEI1,3 1College of Computer, National University of Defense Technology, Changsha 410073, China 2Laboratory of Science and Technology on Integrated Logistics Support, National University of Defense Technology, Changsha 410073, China 3Department of Computer Science, University of California, Davis, USA yE-mail: [email protected]; [email protected] Received Nov. X, 2013; Revision accepted XX, 2013; Crosschecked XX, 2013 Abstract: Despite the availability of garbage collectors, programmers must manually manage non-memory finite system resources such as file descriptors. Resource leaks can gradually consume all available resources and cause programs to raise resource exhaustion exceptions. However, programmers commonly provide no effective recovery for resource exhaustion exceptions, which often can cause programs to halt without completing their tasks. In this paper, we propose to automatically recover programs from resource exhaustion exceptions caused by resource leaks. We transform programs so that they can catch resource exhaustion exceptions, collect leaked resources, and then retry failed code. A resource collector is designed to identify leaked resources and safely release them. We implement our approach for Java programs. Experimental results show that our approach can successfully handle resource exhaustion exceptions caused by reported resource leaks and allow programs to continue to complete their tasks with an average execution time increase of 2.52% and negligible byte-code size increases. Key words: Failure avoidance, Resource leaks, Resource collection, Exception handling, Reliability doi:XX/jzus.C1000000 Document code: A CLC number: 1 Introduction bug that occurs when the cleanup method of the re- source is not invoked after its last use. Resource leaks Automatic garbage collection has gained con- are common in Java programs (Torlak and Chandra, siderable success in many mainstream programming 2010). Growing resource leaks can degrade an appli- languages, such as Java and C#. A garbage col- cation’s performance and can even result in system lector relieves programmers from manual memory crashes due to resource exhaustion. management and improves productivity and pro- gram reliability (Dybvig et al., 1993). However, The large majority of modern programs rely on there are many other non-memory finite system re- exception handling constructs to notify abnormal sit- sources (e.g. file descriptors and database connec- uations and allow customized recoveries from excep- tions) that programmers must manage manually. For tions. When a semantic error occurs or some ex- programs written in Java-like languages, once ac- ceptional situation is encountered, an exception is quired, a resource must be released by explicitly call- thrown (e.g. throw in Java). This exception causes ing a cleanup method. A resource leak is a software the control flow to transfer from where the excep- tion occurs to a point where the exception is caught z Corresponding author * Projects (Nos. 61379054 and 91318301) supported by the (e.g. try and catch in Java). If an exception is not National Natural Science Foundation of China, and Projects caught within the method where it occurs, it is im- (No. 2012AA011201) supported by National High Technology Research and Development Program of China (863 program) plicitly propagated to the caller of this method. If all ⃝c Zhejiang University and Springer-Verlag Berlin Heidelberg 2013 available resources are consumed (or leaked), a fur- 2 Dai et al. / J Zhejiang Univ-Sci C (Comput & Electron) ther request for such resources will typically cause This paper presents an approach to automat- the program to throw a resource exhaustion excep- ically recover from REEs caused by resource leak- tion (REE). For example, a Java program will throw s by collecting leaked resources and make the pro- a FileNotFoundException saying “Too many open gram execution able to proceed to complete its task. files" when no more available file descriptors can be Our approach has two key components. The first used to open a file. component is the program transformer that analyzes Programmers can catch exceptions and provide the program, finds method calls where REEs can be their recovery code. However, the recovery code pro- thrown and transforms the program by adding recov- vided by the the programmer is often unsatisfacto- ery code for REEs. The recovery strategy consists of ry. The Java code in Fig. 1a is such an example. collecting leaked resources first and then retrying the This code snippet is from an old version of Ant1 exception-throwing method calls. We require that and is the running example used throughout this pa- the REE-throwing method is failure atomic (Fetzer per. The programmer opens a pattern file in line et al., 2004) (i.e., the method leaves the program in 5 but forgets to close it. If this method is repeat- a consistent state before exceptions are propagated edly called in cases where there are many pattern to its caller). For example, the transformed result files for a task, the available file descriptors can be for the exception-throwing code in the lines 2 and exhausted. The file open (line 3) can fail with a 3 in Fig. 1a is presented in Fig. 1b2. The sec- thrown FileNotFoundException that is caught (line ond component is the resource collector (called by 6). The recovery code for this exception provided by System.rc() in the line 6 in Fig. 1b) that collects the programmer is disappointing because the pro- leaked resources. First, the resource collector identi- grammer just logs this exception, re-throws anoth- fies leaked resources as the unreleased and unreach- er exception and terminates the execution of this able resources. For garbage collected languages, we method (line 9), without any recoveries. The fur- adapt the garbage collector to retain leaked resources ther the exception propagates from this method, the during garbage collections. Second, corresponding less likely the program can be successfully recovered cleanup methods such as close of BufferedReader from it. This usually causes the entire program to for the code in Fig. 1a are invoked to safely release halt without completing the task. Instead of an ex- these leaked resources in the right order. We ensure ceptional case, this logging-rethrowing-terminating the safety of the resource collector by guaranteeing strategy is common for exception handling accord- that when a resource is released there are no objects ing to recent studies (Shah et al., 2010; Cabral and that depend on it and that have some actions (e.g., Marques, 2007). close and finalize) to perform in the future, and Designing effective recovery strategies for excep- this resource does not refer to resources that may be tions (i.e. recovering from exceptional states and manipulated later by the program. continuing the execution of the program to complete We implement our approach based on Soot its task) is difficult. When encountering a resource (Vallée-Rai et al., 1999) and Jikes RVM (Arnold exhaustion exception, programmers typically do not et al., 2000) for Java programs. The input to our know where to find available resources. Existing ex- approach is REEs as well as their corresponding ception recovery approaches (Carzaniga et al., 2013; resource specifications. We conduct a series of ex- Chang et al., 2009) cannot avoid failures manifested periments to evaluate the effectiveness and overhead as REEs. Even if they can fix the causal resource of our approach on standard benchmarks in litera- leak, there is no available resources to complete the ture and reported resource leaks from real-world pro- task without collecting leaked resources. Consider- grams. The experimental results show that our ap- ing the abundance of resource leaks and the poor proach can successfully recover from REEs caused by quality of exceptional handling, REEs pose a great 2Our approach actually transforms the method threat to the reliability of programs. FileInputStream(File) that is called by FileReader(File). We only transform calls to source methods of REEs. See 1In current version of Ant, the opened file is closed within Section 2 for details. The transformation in Fig. 1b is for a finally statement at the end of this method. Howev- illustration. All classes in this paper are from the Java sys- er, the handling code for the IOException (superclass of tem library unless explicitly stated otherwise. We omit the FileNotFoundException) remains. package name for brevity without confusions. Dai et al. / J Zhejiang Univ-Sci C (Comput & Electron) 3 1 private void readPatterns(File patternfile, …) throws BuildException { 1 FileReader reader = null ; 2 try { BufferedReader patternReader = 2 try { 3 new BufferedReader( new FileReader(patternfile)); 3 reader = new FileReader(patternfile); 4 // Create one NameEntry in the pattern list for each line in the file. 4 } catch (FileNotFoundException e) { 5 … 5 if (e.getMessage().contains("Too many open files")) { 6 } catch (IOException ioe) { 6 System.rc(e); // collect leaked files 7 String msg = "An error occurred while reading from pattern file: " 7 reader = new FileReader(patternfile); 8 + patternfile; 8 } else 9 throw new BuildException(msg, ioe); 9 throw e; 10 } 10 } 11 } 11 BufferedReader patternReader = new BufferedReader (reader ); (a) (b) Fig. 1 The left part (a) is an example code snippet from Ant, and the right part (b) is the transformed result for the lines 2 and 3 from the left part these reported resource leaks and make the programs Resource Specification Resource able to continue to complete their tasks. The run- Collection time overhead for benchmark programs is very low, REE around 3%, and the average execution time increase Hardened is 2.56%.