Refactoring for Reentrancy

I was spectacularly unimpressed by this paper and the Reentrancy tool. There are three strikes against it by my count. First is it's poor applicability, second is its poor performance gain, and third is its ability to damage exceptions.

Several times throughout the paper it is mentioned that this tool does not correctly handle programs that interact with their environment, including the use of the standard system output, accessing files, and accessing databases (not explicitly mentioned but heavily implied by its inability to handle other environmental data sources). Too many programs, especially ones that put enough strain on a system to justify multiprocessing rely on access to these outside data sources as a necessity, and having to completely re-work your program to handle and remove these things is going to be too much of a headache in any major application. While it makes perfect sense that this is necessary it removes too many programs from having this applied right out of the gate (without significant work on accessing libraries to better handle these accesses).

Secondly, the performance gain, in only 3 out of 5 test benchmarks does not give this refactoring program a passing grade. While that is a harsh assessment the authors even admit point blank that the performance gain in these 3 points is small. Big enough to notice but not large enough to have a big impact on the overall program efficiency. Given the amount of rework that will be necessary to get most modern programs to a point where you can apply the reentrancy tool I'm unconvinced that the meager performance gains are worth the trouble.

Which brings me to the last major issue. On page 7 the authors make note that their program cannot guarantee that certain structures remain coherent concerning exceptions. They also make the rediculous claim that "typically this does not pose problems". While I would agree that many exception statements are added in order to conform to coding standards or library usage and thus aren't added directly by choice of the programmer anything that makes a program less stable and helpful during debugging is something to generally avoid. I keep thinking of trying to find the root cause of some memory issue, going through the stack trace then being stopped when the reentrancy tool has broken the trace. That would make for some gloriously frustrating time.

So, with its performance gains small, its ability to break debugging when we only have the authors' assurances that this is an edge case, and with its inability to handle data accesses of any sort this tool clearly needs a lot of work to demonstrate true usefulness for the industry.