OOPSLA '09: Workshop on Refactoring Tools (WRT)

Extracing Concurrency

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:

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.

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:


comments powered by Disqus