Concurrency-related refactorings for JDT

Project Lead: Benjamin Muskalla (IRC: benny`work)

Mentor: Ahti Kitsik (IRC: ahtik)

This project is part of the Google Summer of Code 2008

Abstract

Prices of multi-core cpus are dropping and the move of multi-core processors to desktop machines doesn't stand still. There is a growing need of software developers to handle with concurrency-related problems in their application in order to improve the scalability. Today Moore's law is not applicable in the original sense as parallel computing increases. This idea growed up out of these reasons. Todays developers are all aware of the complexity of concurrent development but cannot handle this complexity very well. In many cases it's not possible to detect such problems with static or dynamic code analysis which implies that developers need to take care of it. The main idea of this project is not to solve concurrency problems but to help the developer to concentrate on the real hard things and eliminate the machine-solvable problems.

The whole proposal can be found here (pdf).

Primary goals

Legend

Needs some investigation/research

Work in progress

Bug fixed / Feature added

Concurrency-aware refactorings

• Inline synchronized method - The "Inline method" refactoring currently ignores the synchronized modifier. See bug 112100

Concurrency-related refactorings & quickfixes

Merge locks

One idea to improve the usability of refactorings in due consideration of concurrency is to merge different synchronized blocks into one. In the case the devel- oper sees that two synchronize blocks (with the same lock) could be merged to one single block to avoid context switching. This fits into the category of quick assists invoked by the user on demand. I don't see a chance (at the moment) to detect such cases without the knowledge of the dynamic behavior of the source passage under stress. This is a typical case of what I meant in the introduction. The developer has to decide about the real problem and JDT should just help him to make the code clean as he want it to be.

Split/stripe locks

Splitting or striping locks helps to reduce the size of synchronized blocks. Splitting the lock at an specific position should not be the problem with this as long as the user provides informations where to split it. Maybe it's possible with some research to come up with some magic to have an automated partition of the lock depending on the static analysis (at least for trivial code ows). I don't see \the magic" as something which should definitely be implemented but could be continually improved.

Convert between lock types

Everything is fine with the usage of the synchronized statement. But projects are more and more migrat- ing to J2SE 5 where new synchronization mechanisms are available. As those should only be used if there is a need for the advanced features of eg. Reentrant- Lock there is no anchor for a compiler warning or error. But we should consider to help the developer by providing quick assists to transform the code be- tween different synchronization styles. An example is the convert between a synchronized block/method and the usage of a ReentrantLock. This would help the developer to not care about stuff like releasing the lock in a finally block as this can be done by the quick assist.

Introduce lock

Maybe the definition is a bit too vague - that goal is not to find concurrency problems and introduce a new lock or something like that. The usecase here is rather simple. When we have cases where a lock is needed due to a compile error like passing null as lock to a synchronize statement, this refactoring has it's big coming out. It should be very similar to the \Introduce field" quick fix with some slight modifications like a better guessed name, private and final modifiers, initiating a new Object directly. These are just some ideas which apply to my coding style but need to be discussed again with a broader audience.

New compiler warnings

• Avoid non-final locks
• Lock not released in all paths
• Usage of volatile arrays
• Avoid global locks

Available features

Here we will list all the features which are currently available in the plugin.

Compile warnings for non-final locks

Many developers have the need that every lock should be final to not change the lock inside the synchronized block. The plugins adds a new compiler warning which checks every used lock of synchronized statements wether they are final. In order to quickly fix this warning, a new quickfix was introduced to react to this warning in order to turn the field into a final field.

Timeline

Here is a complete list of the milestones and release candidates planned for this plugin.

Milestone	Date	Planned items
M1	June 16	Avoid non-final locks, Usage of volatile arrays, Introduce lock
M2	June 28	Lock not released in all paths, Avoid global locks
M3	July 15	Inline synchronized method, Debugging concurrency problems, Convert between lock types
M4	July 26	Merge locks, Split/stripe locks
M5	July 31	bug fixing, community suggestions
RC1	August 4	critical bugs, documentation
RC2	August 8	documentation
Pencils down	August 11	-

Community Proposals

Extract to FutureTask

java.util.concurrent.FutureTask (and its embedded Callable) should be offered as template for "Surround with". Additionally a java.util.concurrent.Executor should be provided in some form to run the task. Moritz Post