cargaji/tfm-report
cargaji/tfm-report
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

Added more Comments in 5

Browse source
This commit is contained in:
Sergio Pérez 2019-12-09 11:08:58 +00:00
parent 7df29f58b7
commit 7ae9bc49f2
1 changed files with 5 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
Secciones/state_of_the_art.tex
View file

@ -7,15 +7,15 @@
\deleted{S}\added{Program s}licing was proposed \cite{Wei81} and \added{iteratively }improved\sergio{un par de citas de papers intermedios que haya} until the proposal of the current\added{ly} \deleted{system}\added{most used program representation structure,} \deleted{(}the SDG\deleted{)} \carlos{(citation)}. Specifically\added{,} in the context of exceptions, multiple approaches have been attempted\deleted{,} with varying\sergio{diverse?} degrees of success. There exist commercial solutions for various programming languages: \carlos{name them and link}.
In the realm of academia, there exists no definite solution. One of the most relevant initial proposal\added{s} \added{was Allen and Horwitz (}\cite{AllH03}\added{)}, although \added{it was} not the first one \deleted{\cite{SinH98,SinHR99}} \deleted{to} target\added{ing} Java \added{programming language} specifically\added{(\cite{SinH98,SinHR99})}.
\deleted{It}\added{In \cite{AllH03}, Allen and Horwitz benefit from the}\deleted{uses} the existing proposals for \textit{return}, \textit{goto} and other unconditional jumps\sergio{anyadir citas} to model the behavior of \textit{throw} statements. Control flow inside \textit{try-catch-finally} statements \deleted{is}\added{was} simulated, both for explicit \textit{throw} and \added{all possible \textit{throws}} nested inside a method call. The base algorithm is presented, and then the proposal is detailed as changes. Unchecked exceptions are considered but regarded as ``worthless'' to include, due to the increase in size of the slices, which reduces their effectiveness as a debugging tool. This is due to the number of unchecked exceptions embedded in normal Java instructions, such as \texttt{NullException} in any instance field or method, \texttt{IndexOutOfBoundsException} in array accesses and countless others. On top of that, handling \textit{unchecked} exceptions opens the problem of calling an API to which there is no analyzable source code, either because the module was compiled before-hand or because it is part of a distributed system. The first should not be an obstacle, as class files can be easily decompiled. The only information that may be lost is variable names and comments, which \added{do not}\deleted{don't} affect a slice's precision, only its readability.
\deleted{It}\added{In \cite{AllH03}, Allen and Horwitz benefit from the}\deleted{uses} the existing proposals for \textit{return}, \textit{goto} and other unconditional jumps\sergio{anyadir citas} to model the behavior of \textit{throw} statements. Control flow inside \textit{try-catch-finally} statements \deleted{is}\added{was} simulated, both for explicit \textit{throw} and \added{all possible \textit{throws}} nested inside a method call. \sergio{\{}The base algorithm is presented, and then the proposal is detailed as changes.\sergio{\} useless sentence} \deleted{U}\added{In that work, u}nchecked exceptions \deleted{are}\added{were} considered but regarded as ``worthless'' to include, due to the increase in size of the slices, which reduces their effectiveness \sergio{\{}as a debugging tool\sergio{\}cuidao con esto de debugging tool}. \added{The reason for this decision, was}\deleted{This is due to} the number of unchecked exceptions embedded in normal Java instructions, such as \texttt{NullException} in any instance field or method, \texttt{IndexOutOfBoundsException} in array accesses and countless others\added{, which would entail an exhaustive analysis of the code looking for every potential instruction that may arise all kinds of unchecked exceptions}. On top of that, handling \textit{unchecked} exceptions opens the problem of calling an API to which there is no analyzable source code, either because the module was compiled before-hand or because it is part of a distributed system. \sergio{\{}The first should not be an obstacle, as class files can be easily decompiled. The only information that may be lost is variable names and comments, which \added{do not}\deleted{don't} affect a slice's precision, only its readability.\sergio{\}$\leftarrow$ delete. Presentamos lo que hicieron, no hay que dar soluciones que no propongamos durante la tesis.}
Chang and Jo \cite{JoC04} present an alternative to the CFG by computing exception-induced control flow separately from the traditional control flow computation, but go no further into the ramifications it entails for the PDG and the SDG.
Chang and Jo \cite{JoC04} present an alternative to the CFG by computing exception-induced control flow separately from the traditional control flow computation, but go no further into the ramifications it entails for the PDG and the SDG.\sergio{Estos curraban con algun lenguaje concreto o con el CFG en general y au?}
Jiang et al. \cite{JiaZSJ06} describe\deleted{s} a solution specific for the exception system in C++, which differs from Java's implementation of exceptions. They reuse the idea of non-executable edges in \textit{throw} nodes, and introduce handling \textit{catch} nodes as a switch, each trying to catch the exception before deferring onto the next \textit{catch} or propagating it to the calling method. Their proposal is center\added{ed} around the IECFG (Improved Exception Control-Flow Graph), which propagates control dependencies onto the PDG and then the SDG. Finally, in their SDG, each normal and exceptional return and their data output are connected to all \textit{catch} statements where the data may have arrived, which is fine for the example they propose, but could be inefficient if the method has many different call nodes.
Jiang et al. \cite{JiaZSJ06} describe\deleted{s} a solution specific for the exception system in C++, which differs from Java's implementation of exceptions. They reuse the idea of non-executable edges in \textit{throw} nodes, and introduce handling \textit{catch} nodes as a switch, each trying to catch the exception before deferring onto the next \textit{catch} or propagating it to the calling method. Their proposal is center\added{ed} around the IECFG (Improved Exception Control-Flow Graph), which propagates control dependencies onto the PDG and then the SDG. Finally, in their SDG, each normal and exceptional return and their data output are connected to all \textit{catch} statements where the data may have arrived, which is fine for the example they propose, but could be inefficient if the method has many different call nodes.\sergio{Si nosotros lo hacemos mejor que ellos es bueno momento de echarnos flores. Example (si fuera el caso): their approach was able to add catches to define control dependencies between instructions after the try-catch block and the catch clauses, but their switch like structure forces to include all non-related catch clauses, which made is non usable for Java, where the exception types are represented in a inheritance system.}
Others \cite{PraMB11} have worked specifically on the C++ exception framework. \carlos{remove or expand}.
Others \cite{PraMB11} have worked specifically on the C++ exception framework. \carlos{remove or expand}.\sergio{expand o juntarlo con el de arriba, que es tambien C++, pero decir algo.}
Finally, Hao \cite{JieS11} introduced a Object-Oriented System Dependence Graph with exception handling (EOSDG), which represented a generic object-oriented language, with exception handling capabilities. Its broadness allows for the EOSDG to fit into both Java and C++. It uses concepts from Jiang \cite{JiaZSJ06}, such as cascading \textit{catch} statements, while adding explicit support for virtual calls, polymorphism and inheritance.
Finally, Hao \cite{JieS11} introduced a Object-Oriented System Dependence Graph with exception handling (EOSDG), which represented a generic object-oriented language, with exception handling capabilities. Its broadness allows for the EOSDG to fit into both Java and C++. It uses concepts from Jiang \cite{JiaZSJ06}, such as cascading \textit{catch} statements, while adding explicit support for virtual calls, polymorphism and inheritance.\sergio{Es completo? trata los casos que solucionamos? se centra en modelar pero no es util para slicing? Extenderlo un poquito mas}
% TODO UNCOMPLETE