# An Automated Refactoring Approach to Improve IoT Software Quality
## 4 Refactoring for Fine-Grained ReentrantReadWriteLocks
### Side Effect Analysis  
An operation, method or expression has a side effect if it modifies the state outside its local environment. Our side effect analysis is to identify whether the critical section has side effects. WALA uses the Intermediate Representation (IR) structure to get all instructions in the method. The WALA IR is the central data structure that represents the instructions of a particular method. The IR represents a method's instructions in a language close to JVM bytecode, but in an SSA-based  
Figure 5: splitting of _RentrantReadWriteLocks_  
register transfer language which eliminates the stack abstraction, it relies instead on a set of symbolic registers. As shown in the code in Figure 6, we analyze each instruction in the method and generate a sequence string for read and write operations for each method.  
The side-effect analysis algorithm is shown in Figure 6. We first get all the instructions in the method and store them in a collection (Line 4), then traverse each instruction and analyze the side effects using the method _getAnalysis_ (Line 14). The analysis method determines whether there is any instruction that modifies the memory. If the instruction is _InvokeInstruction_, the analysis method will get the called method, and the instruction in the method will be traversally analyzed. The method has side effects if it has a write instruction.  
As _ReentrantReadWriteLocks_ have many types of locking modes, such as read/write locks, lock degrading and lock splitting, the use of lock modes depends on the side effects of the critical section. The side-effect analysis will analyze the critical section and generate a character sequence.  
To match the character sequence, we define five regular expressions for inferring lock modes. The regulation sequence and representation of the characters are shown in Table 1.  
Regulation 1: The read lock mode.  
Regulation 1 shows the read lock mode, in which the critical section has at least one read operation and does not have write operations.  
Regulation 2: The write lock mode.  
Regulation 2 represents a mode in which the critical section has at least one write operation.  
Regulation 3: The lock downgrading mode.  
Regulation 3 represents a mode in which a critical section has an _if_ statement that has write operations and at least one read operation in the end.  
Regulation 4: The lock splitting mode.  
Regulation 4 represents a mode in which a critical section only has one _if_ statement and has write operations in the body of statement.  
Regulation 5: The lock splitting mode.  
\begin{table}
\begin{tabular}{l c} \hline \hline
**Regulation** & **Sequence** \\ \hline Regulation 1 & \(R^{+}\) \\ Regulation 2 & \(((C|T)^{*}|(R|W)^{*})^{*}\) \\ Regulation 3 & \(R^{*}CR^{*}W(W|R)^{*}T\) \\ Regulation 4 & \(R^{+}W^{*}|W^{+}R^{+}\) \\ Regulation 5 & \(R^{*}CR^{*}W(W|R)^{*}TR^{+}\) \\ \hline \hline \end{tabular}
\end{table}
Table 1: Regulation sequence and character representation.  
Figure 6: Algorithm for side-effect analysis  
Regulation 5 represents the separation of read and write operations in the critical section.  
We now describe the refactoring algorithm in more detail. The code in Figure 7 first gets the monitor object of the method \(m\) (Line 2), and then checks it in the lock set _lockmap_. If the monitor object exists in _lockmap_, the corresponding lock field is obtained. Otherwise, it creates an appropriate lock field based on the type of the monitor object and presents a new mapping relationship in _lockmap_.  
After the lock field is obtained, the synchronizing methods and synchronized blocks are refactored accordingly. For a synchronizing method (Line 19), the method is analyzed first by side effect analysis, and the corresponding reading and writing sequence is generated. A finite automaton is used to identify the reading and writing sequence (Line 20). Because the monitor object in the synchronized block may have aliases, alias analysis is included in all methods for refactoring the synchronized blocks (Line 27).