Automatic recovery from resource exhaustion exceptions by collecting leaked resources

Despite the availability of garbage collectors, programmers must manually manage non-memory finitesystem 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...

Full description

Saved in:
Bibliographic Details
Published in:Frontiers of information technology & electronic engineering 2014-08, Vol.15 (8), p.622-635
Main Authors: Dai, Zi-ying, Mao, Xiao-guang, Chen, Li-qian, Lei, Yan
Format: Article
Language:English
Subjects:
Availability
Communications Engineering
Computer Hardware
Computer Science
Computer Systems Organization and Communication Networks
Electrical Engineering
Electronics and Microelectronics
Garbage
Instrumentation
Networks
Programmers
Recovery
Citations: Items that this one cites
Online Access:Get full text
Tags: Add Tag
No Tags, Be the first to tag this record!
Description
Summary:Despite the availability of garbage collectors, programmers must manually manage non-memory finitesystem 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 approach for resource exhaustion exceptions, which often causes 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 to catch resource exhaustion exceptions, collect leaked resources, and then retry the failure 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 complete their tasks with an average execution time increase of 2.52% and negligible bytecode size increase.
ISSN:1869-1951
2095-9184
1869-196X
2095-9230
DOI:10.1631/jzus.C1300352