# HG changeset patch
# User Thomas Wuerthinger <thomas@wuerthinger.net>
# Date 1304326833 -7200
# Node ID 28a8b3c8b9b4d70c5db7c02fbfe0301e39930028
# Parent  95a9b8906b09e3639802f6fde45dfec82f3eec54
Small fix to documentation.

diff -r 95a9b8906b09 -r 28a8b3c8b9b4 doc/design/graal_compiler.pdf
Binary file doc/design/graal_compiler.pdf has changed
diff -r 95a9b8906b09 -r 28a8b3c8b9b4 doc/design/graal_compiler.tex
--- a/doc/design/graal_compiler.tex	Mon May 02 10:56:35 2011 +0200
+++ b/doc/design/graal_compiler.tex	Mon May 02 11:00:33 2011 +0200
@@ -192,7 +192,7 @@
 
 \subsection{Frame States}
 Frame states capture the state of the program, in terms of the source representation (e.g., Java state: local variables, expressions, ...).
-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.
+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.
 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.).
 Thus, frame states need only be generated for bytecodes that cannot be reexecuted: putfield, astore, invoke, monitorenter/exit, ...