The Impact of Program Reduction on Automated Program Repair

TL;DR

This paper tackles the scalability of automated program repair (APR) by applying dynamic program slicing to produce a reduced, bug-relevant program. By integrating ORBS-based slicing with a template-based APR (TBar) and a test-suite reduction strategy, the authors demonstrate substantial reductions in patch-validation time and fault-localization effort on the Defects4J dataset, with patch quality largely preserved. The approach yields large time savings but is not universally beneficial, as some bugs become unpatchable under aggressive reductions. Overall, the work provides evidence that program reduction can improve APR performance in practice and outlines avenues for extending these gains to other APR paradigms and optimization strategies.

Abstract

Correcting bugs using modern Automated Program Repair (APR) can be both time-consuming and resource-expensive. We describe a program repair approach that aims to improve the scalability of modern APR tools. The approach leverages program reduction in the form of program slicing to eliminate code irrelevant to fixing the bug, which improves the APR tool's overall performance. We investigate slicing's impact on all three phases of the repair process: fault localization, patch generation, and patch validation. Our empirical exploration finds that the proposed approach, on average, enhances the repair ability of the TBar APR tool, but we also discovered a few cases where it was less successful. Specifically, on examples from the widely used Defects4J dataset, we obtain a substantial reduction in median repair time, which falls from 80 minutes to just under 18 minutes. We conclude that program reduction can improve the performance of APR without degrading repair quality, but this improvement is not universal. A replication package is available via Zenodo at https://doi.org/10.5281/zenodo.13074333. Keywords: automated program repair, dynamic program slicing, fault localization, test-suite reduction, hybrid techniques.

Figures (10)

• Figure 1: The lattice of all possible configurations of program ($\mathcal{P}$ or $\mathcal{P}_{S}$), test suite ($\mathcal{T}$, or $\mathcal{T}_{S}$), and suspicious locations list ($\mathcal{L}$, $\mathcal{L}_{S}$, or $\mathcal{L}_{P}$).
• Figure 2: Reduction's impact on each program's SLoC.
• Figure 3: Reduction's impact on each program's TSS.
• Figure 4: Reduction's impact on each program's $\mathcal{L}$.
• Figure 5: Reduction in test-suite size's impact on each project's NTE.