[pypy-svn] r78070 - pypy/extradoc/talk/pepm2011

[cfbolz at codespeak.net]

Author: cfbolz
Date: Mon Oct 18 19:47:50 2010
New Revision: 78070

Modified:
   pypy/extradoc/talk/pepm2011/escape-tracing.pdf
   pypy/extradoc/talk/pepm2011/paper.tex
Log:
add line numbers, try to gently rewrite things a bit


Modified: pypy/extradoc/talk/pepm2011/escape-tracing.pdf
==============================================================================
Binary files. No diff available.

Modified: pypy/extradoc/talk/pepm2011/paper.tex
==============================================================================
--- pypy/extradoc/talk/pepm2011/paper.tex	(original)
+++ pypy/extradoc/talk/pepm2011/paper.tex	Mon Oct 18 19:47:50 2010
@@ -575,26 +575,29 @@
 bit peculiar in that it receives no static input arguments for the trace,
 but it is only used to optimize operations within the trace.
 
-To optimize the trace, it is traversed from beginning to end.
-Whenever a \lstinline{new} operation is seen, the operation is removed and a \emph{static
-object}\footnote{Here ``static'' is meant in the sense of partial
-evaluation, \ie known at partial evaluation time, not in the sense of static
-allocation or static method.} is constructed and associated with the variable
-that would have stored
-the result of \lstinline{new}. The static object describes the shape of the
-original object, \eg where the values that would be stored in the fields of the
-allocated object come from, as well as the type of the object. Whenever the
-optimizer sees a \lstinline{set} that writes into such an object, that shape
-description is updated and the operation can be removed, which means that the
-operation was done at partial evaluation time. When the optimizer encounters a
-\lstinline{get} from such an object, the result is read from the shape
-description, and the operation is also removed. Equivalently, a
-\lstinline{guard_class} on a variable that has a shape description can be removed
-as well, because the shape description stores the type and thus the outcome of
-the type check the guard does is statically known.
+To optimize the trace, it is traversed from beginning to end. Every
+optimization in the input trace is either removed, or new operations are
+produced. Whenever a \lstinline{new} operation is seen, the operation it is
+removed optimistically and a \emph{static object}\footnote{Here ``static'' is
+meant in the sense of partial evaluation, \ie known at partial evaluation time,
+not in the sense of static allocation or static method.} is constructed and
+associated with the result variable. The static object describes the shape of
+the original object, \ie where the values that would be stored in the fields of
+the allocated object come from, as well as the type of the object.
+
+When a \lstinline{set} that writes into a static object is optimized, the
+corresponding shape description is updated and the operation is removed. This
+means that the operation was done at partial evaluation time. When the
+optimizer encounters a \lstinline{get} from a static object, the result is read
+from the shape description, and the operation is also removed. Equivalently, a
+\lstinline{guard_class} on a variable that has a shape description can be
+removed as well, because the shape description stores the type and thus the
+outcome of the type check the guard does is statically known. Operations that
+have dynamic (\ie all other) objects as arguments are just left untouched by
+the optimizer.
 
-In the example from Section~\ref{sub:example}, the following operations in the upper half
-of Figure~\ref{fig:unopt-trace} produce two
+In the example from Section~\ref{sub:example}, the following operations
+of Figure~\ref{fig:unopt-trace} (lines 10-17) produce two
 static objects, and can be completely removed from the optimized trace:
 
 \begin{lstlisting}[mathescape,xleftmargin=20pt]
@@ -604,15 +607,13 @@
 set($p_{6}$, intval, -100)
 \end{lstlisting}
 
-
-The static object associated with $p_{5}$ would know that it is a
+The static object associated with $p_{5}$ would store the knowledge that it is a
 \lstinline{BoxedInteger} whose \lstinline{intval} field contains $i_{4}$; the
-one associated with $p_{6}$ would know that it is a \lstinline{BoxedInteger}
+one associated with $p_{6}$ would store that it is a \lstinline{BoxedInteger}
 whose \lstinline{intval} field contains the constant -100.
 
-The subsequent operations in Figure~\ref{fig:unopt-trace},
- which use $p_{5}$ and $p_{6}$, could then be
-optimized using that knowledge:
+The subsequent operations (line 19-29) in Figure~\ref{fig:unopt-trace}, which
+use $p_{5}$ and $p_{6}$, can then be optimized using that knowledge:
 
 \begin{lstlisting}[mathescape,xleftmargin=20pt]
 guard_class($p_{5}$, BoxedInteger)
@@ -635,18 +636,20 @@
 
 The rest of the trace from Figure~\ref{fig:unopt-trace} is optimized similarly.
 
+
 So far we have only described what happens when static objects are used in guards and in
 operations that read and write fields. When the static
 object is used in any other operation, it cannot remain static. For example, when
 a static object is stored in a globally accessible place, the object has to
-be allocated, as it might live longer than one iteration of the loop
-and because the partial evaluator looses track of it. This means that the static
+be allocated, as it might live longer than one iteration of the loop and as
+arbitrary \lstinline{set} operations could change it due to aliasing. This
+means that the static
 object needs to be turned into a dynamic one, \ie lifted. This makes it
 necessary to put operations into the residual code that allocate the
 static object at runtime.
 
 This is what happens at the end of the trace in Figure~\ref{fig:unopt-trace}, when the \lstinline{jump} operation
-is hit. The arguments of the jump are at this point static objects. Before the
+is optimized. The arguments of the jump are at this point static objects. Before the
 jump is emitted, they are \emph{lifted}. This means that the optimizer produces code
 that allocates a new object of the right type and sets its fields to the field
 values that the static object has (if the static object points to other static
@@ -670,26 +673,26 @@
 and \lstinline{guard_class} operations).
 
 \begin{figure}
-\begin{lstlisting}[mathescape,numbers=left,escapechar=|]
+\begin{lstlisting}[mathescape,numbers=right,escapechar=|,numberstyle = \tiny,numbersep=0pt, numberblanklines=false]
 # arguments to the trace: $p_{0}$, $p_{1}$ |\setcounter{lstnumber}{2}|
-guard_class($p_1$, BoxedInteger)
+guard_class($p_1$, BoxedInteger)           |\setcounter{lstnumber}{4}|
 $i_2$ = get($p_1$, intval)
-guard_class($p_0$, BoxedInteger)
+guard_class($p_0$, BoxedInteger)           |\setcounter{lstnumber}{7}|
 $i_3$ = get($p_0$, intval)
-$i_4$ = int_add($i_2$, $i_3$)
-$i_9$ = int_add($i_4$, -100)
-|\setcounter{lstnumber}{50}|
-guard_class($p_0$, BoxedInteger) 
-$i_{12}$ = get($p_0$, intval)
-$i_{14}$ = int_add($i_{12}$, -1)
-
-$i_{17}$ = int_gt($i_{14}$, 0)
-guard_true($i_{17}$)
+$i_4$ = int_add($i_2$, $i_3$)              |\setcounter{lstnumber}{25}|
+$i_9$ = int_add($i_4$, -100)               |\setcounter{lstnumber}{35}|
 
-$p_{15}$ = new(BoxedInteger)
-set($p_{15}$, intval, $i_{14}$)
-$p_{10}$ = new(BoxedInteger)
-set($p_{10}$, intval, $i_9$)
+guard_class($p_0$, BoxedInteger)           |\setcounter{lstnumber}{38}|
+$i_{12}$ = get($p_0$, intval)              |\setcounter{lstnumber}{42}|
+$i_{14}$ = int_add($i_{12}$, -1)           |\setcounter{lstnumber}{50}|
+
+$i_{17}$ = int_gt($i_{14}$, 0)             |\setcounter{lstnumber}{53}|
+guard_true($i_{17}$)                       |\setcounter{lstnumber}{42}|
+
+$p_{15}$ = new(BoxedInteger)               |\setcounter{lstnumber}{45}|
+set($p_{15}$, intval, $i_{14}$)            |\setcounter{lstnumber}{26}|
+$p_{10}$ = new(BoxedInteger)               |\setcounter{lstnumber}{28}|
+set($p_{10}$, intval, $i_9$)               |\setcounter{lstnumber}{53}|
 
 jump($p_{15}$, $p_{10}$)
 \end{lstlisting}
@@ -699,7 +702,9 @@
 
 The final optimized trace of the example can be seen in Figure~\ref{fig:step1}.
 The optimized trace contains only two allocations, instead of the original five,
-and only three \lstinline{guard_class} operations, from the original seven.
+and only three \lstinline{guard_class} operations, from the original seven. The
+line numbers are the lines where the operations occurred in the original trace
+in Figure~\ref{fig:unopt-trace}.
 
 \section{Formal Description of the Algorithm}
 \label{sec:formal}