Added Comments in 4.2

Secciones/problem_solution.tex

@@ -191,7 +191,7 @@ This problem cannot be easily solved, as it is a ``dynamic'' one, requiring info
 
 \section{The \texttt{try-catch} statement}
 
-In this section we present an example where the current approximation for the \texttt{try-catch} statement fails to capture all the correct dependencies and excludes from the slice some statements which are necessary for a complete slice (both weak and strong). After that, we generalize the set of cases where that is a problem and its possible appearances in real-life development. Finally, we propose a solution which properly represent all the dependencies introduced by the \texttt{try-catch}, focusing on producing complete strong slices.
+In this section we present an example where the current \deleted{approximation for the}\added{approach used to handle} \texttt{try-catch} statement fails to capture all the correct dependencies \deleted{and excludes}\added{, excluding} from the slice some statements \deleted{which}\added{that} are necessary for a complete slice (both weak and strong). After that, we generalize the set of cases where \deleted{that}\added{the lack of accuracy}\sergio{creo que aqui con ``that" te referias a la precision no?} is a problem and its possible appearances in real-life development. Finally, we propose a solution which properly represent all the dependencies introduced by the \texttt{try-catch}, focusing on producing complete strong slices.
 
 \subsubsection*{The types of control dependence}
 
@@ -199,17 +199,18 @@ In this section we present an example where the current approximation for the \t
 
 Even though it continues to be used for control dependence, definition~\ref{def:ctrl-dep} does not have the same meaning when applied to conditional instructions and loops as it has when applied to unconditional jumps and other complex structures, such as the \texttt{switch} and \texttt{try-catch} statements.
 
-Originally, the definition of control dependence signified that the execution of a statement affected whether or not another one executed (or kept executing). In contrast, unconditional jumps, and \texttt{try-catch} statements' execution do not affect the following instructions; its presence or absence is what generates the control dependency. For those instructions, control dependencies are still generated with the same edges, but require the addition of extra edges to the CFG \cite{BalH93,AllH03}.
+Originally, the definition of control dependence signified that the execution of a statement affected whether or not another one executed (or kept executing)\sergio{$\leftarrow$ no se entiende esta frase. Creo que el whether sobra y el parentesis no lo entiendo}. In contrast, unconditional jumps, and \texttt{try-catch} statements' execution do not affect the following instructions; its presence or absence is what generates the control dependency. For those instructions, control dependencies are still generated with the same edges, but require the addition of extra edges to the CFG \cite{BalH93,AllH03}\sergio{estos son los psedo-predicate edges? Si son los falsos podemos referenciarlos dentro de la tesis, no hara falta irse a los articulos, sino parece que sean unos nuevos edges que no existian hasta le momento}.
 
 \subsection{The control dependencies of a \texttt{catch} block}
 
-In the current approximation for exception handling \cite{AllH03}, \texttt{catch} blocks do not have any outgoing dependence leading anywhere except the instructions it contains. This means that, as showcased in chapter~\ref{cha:introduction}, the only way a \texttt{catch} statement may appear in a slice is if there is a data dependency or one of the statements inside it is needed.
+In the current approximation\sergio{approach?} for exception handling \cite{AllH03}, \texttt{catch} blocks do not have any outgoing dependence leading anywhere except the instructions it contains. This means that, as showcased in chapter~\ref{cha:introduction}, the only way a \texttt{catch} statement may appear in a slice is if \added{the slicing criterion is inside the catch block, or if the value of a variable defined inside the catch block is needed (reaching it by data dependency).}\deleted{there is a data dependency or one of the statements inside it is needed.}
 
-The only occasion in which \texttt{catch} blocks generate any kind of control dependency is when there is an exception thrown that is not covered by any of the \texttt{catch} blocks, and the function may exit with an exception. In that case, the instructions after the \texttt{try-catch} block are dependent on an uncaught exception not being thrown.
+The only occasion in which \texttt{catch} blocks generate any kind of control dependency is when there is an exception thrown that is not covered by any of the \texttt{catch} blocks, and the function may exit with an exception. In that case, the instructions after the \texttt{try-catch} block are dependent on an uncaught exception not being thrown.\sergio{aqui hay arcos a todos los catch? Si es asi acabar la frase diciendo que se considera esa instruccion dependiente de todos los catch o algo asi para que quede mas claro.}
 
-But, compared to the treatment of unconditional exceptions does not match the treatment of \texttt{try-catch} statement: unconditional jumps have a non-executable edge to the instruction that would be executed in their absence; \texttt{catch} statements do not.
+But, compared to the treatment of unconditional \added{jumps?,} exceptions does not match\sergio{quien does not match?} the treatment of \texttt{try-catch} statement: unconditional jumps have a non-executable edge to the instruction that would be executed in their absence; \texttt{catch} statements do not.
 
 \begin{example}[\texttt{catch} statements' outgoing dependencies]
+\label{exa:catch-no-dep}
 	Consider the code shown in figure~\ref{fig:catch-no-dep-code}, which depicts a \texttt{try-catch} where method \texttt{f}, which may throw an exception, is called. The function may throw either a \texttt{ExceptionA}, \texttt{ExceptionB} or \texttt{Exception}-typed exception; and the \texttt{try-catch} considers all three cases, logging the type of exception caught. Additionally, \texttt{f} accesses and modifies a global variable \texttt{x}.
 
 	\begin{figure}[h]
@@ -229,7 +230,7 @@ next;
 		\label{fig:catch-no-dep-code}
 	\end{figure}
 
-	The CFG and PDG associated to that code is depicted in figure~\ref{fig:catch-no-dep-graphs}. As can be seen, the only two elements that are dependent on any \texttt{catch} are the log statement and the unpacking of \texttt{x}. If the following statement used \texttt{x} in any way, all \texttt{catch} statements would be selected, otherwise they are ignored, and not deemed necessary. It is true that they are normally not necessary; i.e., if the slicing criterion was placed on \texttt{next} (line 10), the whole \texttt{try-catch} would be rightfully ignored; but there exist cases where \texttt{f()} (line 2) would be part of the slice, and the absence of \texttt{catch} statements would result in an incomplete slice.
+	The CFG and PDG associated to \deleted{that}\added{the} code \added{of Figure~\ref{fig:catch-no-dep-code}} is depicted in figure~\ref{fig:catch-no-dep-graphs}\added{\footnote{For the sake of clarity, in the PDG of figure~\ref{fig:catch-no-dep-graphs}, \texttt{log} function calls have been represented as a single node instead of their full node structures.}}. As can be seen, the only two elements that are dependent on any \texttt{catch} are the log statement and the unpacking of \texttt{x}. If the following statement used \texttt{x} in any way, all \texttt{catch} statements would be selected, otherwise they are ignored, and not deemed necessary. It is true that they are normally not necessary; i.e., if the slicing criterion was placed on \texttt{next} (line 10), the whole \texttt{try-catch} would be rightfully ignored; but there exist cases where \texttt{f()} (line 2) would be part of the slice, and the absence of \texttt{catch} statements would result in an incomplete slice.
 
 	\begin{figure}[h]
 		\includegraphics[width=\linewidth]{img/catch-no-dep}
@@ -239,7 +240,7 @@ next;
 \end{example}
 
 \begin{example}[Incorrectly ignored \texttt{catch} statements]
-	Consider the code in figure~\ref{fig:incorrect-try-catch-code}, in which a method is called twice: once inside a \texttt{try-catch} statement, and a second time, outside. \texttt{f} also accesses and modifies variable \texttt{x}, which is redefined before the second call to \texttt{f}. Exploring this example, we demonstrate how line 3 will be necessary but not included in the slice.
+	Consider the code in figure~\ref{fig:incorrect-try-catch-code}, in which \deleted{a method}\added{the method \texttt{f}} is called twice: once inside a \texttt{try-catch} statement, and a second time, outside. \added{As it happened in example~\ref{exa:catch-no-dep}}, \texttt{f} also accesses and modifies variable \texttt{x}, which is redefined before the second call to \texttt{f}. Exploring this example, we demonstrate how line 3 will be necessary but not included in the slice.
 
 	\begin{figure}[h]
 		\begin{minipage}{0.5\linewidth}
@@ -266,12 +267,12 @@ void f() throws Exception {
 		\label{fig:incorrect-try-catch-code}
 	\end{figure}
 
-	Figure~\ref{fig:incorrect-try-catch-graph} displays the program dependence graph for the snippet of code on the left side of figure~\ref{fig:incorrect-try-catch-code}. Data dependencies are shown in red, and summary edges in blue. The set of nodes filled in grey represent the slice with respect to a slicing criterion in method \texttt{f} (line 4, \texttt{x}). In the slice, both calls to \texttt{f} and its input (\texttt{x\_in = x}) are included, but the \texttt{catch} block is not present. The execution of the slice may not be the same: if no exception is thrown, there is no change; but if \texttt{x} was odd before entering the snippet, an exception will be thrown and not caught, exiting the program prematurely.
+	Figure~\ref{fig:incorrect-try-catch-graph} displays the program dependence graph for the snippet of code on the left side of figure~\ref{fig:incorrect-try-catch-code}. Data dependencies are shown in red, and summary edges\sergio{esto ya tiene una definicion clara en la seccion del SDG??} in blue. The set of nodes filled in grey represent the slice with respect to \deleted{a}\added{the} slicing criterion \added{$\langle 4, x \rangle$} in method \texttt{f} \deleted{(line 4, \texttt{x})}\sergio{plantearse si poner los SC asi o dejarlo como (line X, variable Y)}. In the slice, both calls to \texttt{f} and its input (\texttt{x\_in = x}) are included, but the \texttt{catch} block is not present. The execution of the slice may not be the same: if no exception is thrown, there is no change; but if \texttt{x} was odd before entering the snippet, an exception \deleted{will}\added{would} be thrown and not caught, exiting the program prematurely.
 
 	\begin{figure}[h]
 		\centering
 		\includegraphics[width=0.9\linewidth]{img/incorrect-try-catch}
-		\caption{The system dependence graph of the left snippet of figure~\ref{fig:incorrect-try-catch-code}. \texttt{f} and the edges that connect to it are not shown for simplicity.}
+		\caption{The \deleted{system dependence graph}\added{SDG} of the left snippet of figure~\ref{fig:incorrect-try-catch-code}. \texttt{f} and the \deleted{edges that connect to it}\added{associated inter-procedural edges} are not shown for simplicity.}
 		\label{fig:incorrect-try-catch-graph}
 	\end{figure}
  	
@@ -280,11 +281,14 @@ void f() throws Exception {
 
 \subsubsection*{A solution for the \texttt{catch}'s lack of control dependencies}
 
-\texttt{catch} statements should be handled like unconditional jumps: a non-executable edge should connect them to the instruction that would run if they were absent. For \texttt{catch} statements, the non-executable edge would connect them to the \texttt{catch} that contains the most immediate super-type (or multiple); or to the error exit, if no other \texttt{catch} could catch the same exception. This would create a tree-like structure among \texttt{catch} statements, with the root of each tree connected to the ``error exit'' of the method. This would generate dependencies between \texttt{catch} statements, and more importantly, dependencies from the \texttt{catch} statements to the instructions that follow the \texttt{try-catch} statement.
+\added{In order to solve the drawback exposed above, we propose the} \texttt{catch} statements \added{to be handled as}\deleted{should be handled like} unconditional jumps \added{were in \cite{}}\sergio{pending Cite}: a non-executable edge should connect them to the instruction that would run if they were absent. For \texttt{catch} statements, the non-executable edge would connect them to the \texttt{catch} that contains the most immediate super-type (or multiple); or to the error exit, if no other \texttt{catch} could catch the same exception. This would create a tree-like structure among \texttt{catch} statements, with the root\sergio{root o leave? si es connect to seria leave, sino seria edge connecting the super-type to catch type} of each tree connected to the ``error exit'' of the method. This would generate dependencies between \texttt{catch} statements, and more importantly, dependencies from the \texttt{catch} statements to the instructions that follow the \texttt{try-catch} statement.
 
 Unfortunately, this creates the same behaviour as with unconditional jumps: all the instructions that follow a \texttt{try-catch} structure is dependent on the presence of the \texttt{catch} statements, which in turn are dependent on all the statements that may throw exceptions. In practice, the inclusion of any statement after a \texttt{try-catch} statement would require the slice to include all \texttt{catch} statements, the statements that may throw exceptions, and all the statements required by control or data dependencies. This is a huge number of instructions just for including the \texttt{catch} statements.
 
-Our solution makes slices complete again, but makes them much less correct. As a solution for the incorrectness, we could insert an additional requirement when including \texttt{catch} blocks: if they are included because of their control dependencies on instructions outside the \texttt{try-catch}, they need to satisfy an additional condition before being in the slice: have a node in the slice which may throw a compatible exception. In order to achieve this, control dependencies whose source is a \texttt{catch} node and its destination is outside that same \texttt{catch} are coloured green and labelled (2). Additional edges are added between every \texttt{catch} and any statement that may throw a compatible exception; are also coloured green, and labelled (1). When traversing the graph, only include \texttt{catch} statements if they are reached through an unlabelled edge or if they are reached by at least one edge with each label (1 and 2). \carlos{Add que solo se pueda atravesar uno de los arcos verdes (una vez llegas a un nodo a traves de un arco verde, no continuas recorriendo arcos verdes)} \carlos{optimizacion 2, que los nodos catch se repitan para cada funcion tenga los suyos propios. El contenido del catch es comun a todos, pero las cabeceras y el despempaquetamiento de variables es individual para cada funcion. De este modo no se coge a todas las funciones. Tambien se podria emplear como alternativa a los arcos etiquetados, creando un set de nodos que no tienen padre, y sirven exclusivamente para que las instrucciones futuras dependan de ellas.}
+\sergio{Lo que viene a continuacion suena a parche y es una contribucion muy tocha, de hecho es nuestra mejor baza.}Our solution makes slices complete again, but makes them much less correct. \deleted{As a solution for the incorrectness}\added{However, analysing the behaviour of the catch dependencies, we propose a new technique to improve the downgraded accuracy. This technique follow the same basis that the one proposed for unconditional jumps, and consists in the insertion of}\deleted{ we could insert} an additional requirement when including \texttt{catch} blocks: if they are included because of their control dependencies on instructions outside the \texttt{try-catch}, they need to satisfy an additional condition before being in the slice: have a node in the slice which may throw a compatible exception. 
+
+\sergio{Esto hay que pulirlo y anyadir un dibujo con los arcos 1 y 2 en verde. El verde no es importante, es solo una senya de identidad en el dibujo. Lo importante es la etiqueta $\rightarrow$ }
+In order to achieve this, control dependencies whose source is a \texttt{catch} node and its destination is outside that same \texttt{catch} are coloured green and labelled (2). Additional edges are added between every \texttt{catch} and any statement that may throw a compatible exception; are also coloured green, and labelled (1). When traversing the graph, only include \texttt{catch} statements if they are reached through an unlabelled edge or if they are reached by at least one edge with each label (1 and 2). \carlos{Add que solo se pueda atravesar uno de los arcos verdes (una vez llegas a un nodo a traves de un arco verde, no continuas recorriendo arcos verdes)} \carlos{optimizacion 2, que los nodos catch se repitan para cada funcion tenga los suyos propios. El contenido del catch es comun a todos, pero las cabeceras y el despempaquetamiento de variables es individual para cada funcion. De este modo no se coge a todas las funciones. Tambien se podria emplear como alternativa a los arcos etiquetados, creando un set de nodos que no tienen padre, y sirven exclusivamente para que las instrucciones futuras dependan de ellas.}
 
 
 % \begin{example}[Order of \texttt{catch} statements]