comparison doc/design/graal_compiler.tex @ 2572:28a8b3c8b9b4

Small fix to documentation.
author Thomas Wuerthinger <thomas@wuerthinger.net>
date Mon, 02 May 2011 11:00:33 +0200
parents 0023bd42eefe
children 6d99b909696d
comparison
equal deleted inserted replaced
2568:95a9b8906b09 2572:28a8b3c8b9b4
190 \item Graphs are 190 \item Graphs are
191 \end{itemize} 191 \end{itemize}
192 192
193 \subsection{Frame States} 193 \subsection{Frame States}
194 Frame states capture the state of the program, in terms of the source representation (e.g., Java state: local variables, expressions, ...). 194 Frame states capture the state of the program, in terms of the source representation (e.g., Java state: local variables, expressions, ...).
195 Whenever a safepoint is reached or \cwi{why is that an ``or'', both is basically the same} a deoptimization is needed a valid frame state needs to be available. 195 Whenever a safepoint is reached or \cw{why is that an ``or'', both is basically the same} a deoptimization is needed a valid frame state needs to be available.
196 A frame state is valid as long as the program performs only actions that can safely be reexecuted (e.g., operations on local variables, etc.). 196 A frame state is valid as long as the program performs only actions that can safely be reexecuted (e.g., operations on local variables, etc.).
197 Thus, frame states need only be generated for bytecodes that cannot be reexecuted: putfield, astore, invoke, monitorenter/exit, ... 197 Thus, frame states need only be generated for bytecodes that cannot be reexecuted: putfield, astore, invoke, monitorenter/exit, ...
198 198
199 Within the node graph a frame state is represented as a node that is fixed between the node that caused it to be generated (data dependency) and the node that invalidates it (control dependency). 199 Within the node graph a frame state is represented as a node that is fixed between the node that caused it to be generated (data dependency) and the node that invalidates it (control dependency).
200 200