OOPSLA '09: Workshop on Refactoring Tools (WRT)

There were two major themes at the WRT this year: concurrency and polyglot refactoring.

Concurrency

I actually prefer the term transforming instead of refactoring for converting sequential code to parallel code but I will use the term refactoring here since other people in the community have embraced it.

Two papers were presented that dealt with refactoring to concurrency in the X10 language:

• Extracting Concurrency via Refactoring in X10
• Concurrency Refactoring for X10

Both papers presented some prototype refactorings. I really liked the presentation of the second paper since it relates directly with the work I am doing on optimization patterns for parallel programming. As you can see from the image above, the tiling operation is one such optimization. It's important to provide such a transformation since you may need to do it to get good performance. Such transformations cannot be done by the compiler since it needs more feedback from the programmer on the size of the tiles which depends on the algorithm and data structures for that particular problem that you are trying to solve. And sometimes tiling might not even solve the problem so you need to know when to tile and when not to tile.

We had a breakout session on the topic of concurrency refactorings and here were the interesting issues (read as future research questions) that came up.

• How to discover what to refactor?
  Profilers and trace based executions can help guide you in this area but they aren't always that intuitive to use. And you don't want to introduce concurrency blindly since it only matters if you are optimizing the real bottlenecks.
• What are some ways to suggest potential refactorings?
  Now that you know where the bottlenecks are, what are some refactorings that you can apply? I believe that parallel patterns are the way to go.
• How do you check that your refactoring is correct?
  Refactoring engines for sequential code have bugs. And with concurrency refactoring you have to be even more careful to not introduce subtle concurrency bugs that can be hard to track down. How would you check the correctness of your transformations statically?
• How do you fine-tune your refactorings?
  Unlike sequential refactorings, concurrency refactorings require more feedback from the user. For instance, the dimensions of the tiles (see picture above). It would help if the IDE can suggest some parameters and then run the profiler automatically to give more feedback.

The work on concurrency refactoring is definitely something that my advisor, Ralph Johnson, and his group at UIUC are interested in as part of our vision for an IDE that can help support parallel programming.

Polyglot Refactoring

Polyglot refactoring is not a standard term. It's one that I coined to describe how refactorings must be aware of all the different components that you use in your program - frameworks, libraries, etc. All these different components are described using different mini DSLs. For instance, the Hibernate configuration files are described in XML, your testing framework uses a set of APIs and conventions that you must conform to, and sometimes you use different languages (Groovy, JRuby, etc) that run on the JVM but share data.

It's important that as you perform the traditional refactoring such as rename, move, etc that you preserve the intended behavior in these other components as well. I think this is not an area that many people have looked at. Researchers focus on having new refactorings for the core language but forget that those other components need to be refactored too leaving a broken program that the user has to fix by hand.

There are three papers that deal with this issue:

• Refactoring in Multiple Representations - Code and Statecharts
• Testing-framework-aware Refactoring
• Toward a Language-Agnostic, Syntactic Representation for Preprocessed Code – this deals with preprocessors which essentially can be viewed as a different language on top of your base language