Refactoring for reentrancy

Jan Wloka, Manu Sridharan, Frank Tip

2009 · 72 citations · 13 references

Concepts

TL;DR

A program is reentrant if distinct executions on distinct inputs cannot affect each other, enabling parallel deployment without extra concurrency control, yet many Java programs are not reentrant because they rely on mutable global state. The study proposes a mostly‑automated refactoring that replaces global state with thread‑local state and runs each execution in a fresh thread to make programs reentrant. The refactoring, implemented in the Eclipse‑based tool Reentrancer, replaces global state with thread‑local state and executes each run in a fresh thread. The refactoring produces programs that are safe for parallel execution, eliminates reentrancy problems in five benchmarks, and yields speedups on a multicore machine for three benchmarks without further code changes.

Abstract

A program is reentrant if distinct executions of that program on distinct inputs cannot affect each other. Reentrant programs have the desirable property that they can be deployed on parallel machines without additional concurrency control. Many existing Java programs are not reentrant because they rely on mutable global state. We present a mostly-automated refactoring that makes such programs reentrant by replacing global state with thread-local state and performing each execution in a fresh thread. The approach has the key advantage of yielding a program that is obviously safe for parallel execution; the program can then be optimized selectively for better performance. We implemented this refactoring in Reentrancer, a practical Eclipse-based tool. Reentrancer successfully eliminated observed reentrancy problems in five single-threaded Java benchmarks. For three of the benchmarks, Reentrancer enabled speedups on a multicore machine without any further code modification.

References

13