cfbolz at codespeak.net cfbolz at codespeak.net
Mon Oct 18 19:07:31 CEST 2010

Author: cfbolz
Date: Mon Oct 18 19:07:26 2010
New Revision: 78061

Modified:
Log:
more small tweaks, still missing a more aggressive rewrite

==============================================================================
Binary files. No diff available.

==============================================================================
+++ pypy/extradoc/talk/pepm2011/paper.tex	Mon Oct 18 19:07:26 2010
@@ -302,6 +302,7 @@
code.

\subsection{Running Example}
+\label{sub:example}

For the purpose of this paper, we are going to use a tiny interpreter for a dynamic language with
a very simple object
@@ -387,6 +388,11 @@

\begin{figure}
+\lstset{
+    numbers = right,
+    numberstyle = \tiny,
+    numbersep = 0pt
+}
\begin{lstlisting}[mathescape]
# arguments to the trace: $p_{0}$, $p_{1}$
@@ -558,10 +564,10 @@
\label{sec:statics}

The main insight to improve the code shown in the last section is that objects
-in category 1 do not survive very long -- they are used only inside the loop and
-there is no other outside reference to them. The idea for improving
-the code is to analyze which objects fall in category 1 and therefore do
-not have to be allocated at all.
+in category 1 do not survive very long -- they are used only inside the loop
+and there is no other outside reference to them. Therefore the optimizer
+identifies objects in category 1 and removes the allocation of these objects,
+and all operations manipulating them.

This is a process that is usually called \emph{escape analysis}
\cite{goldberg_higher_1990}. In this paper we will
@@ -587,7 +593,7 @@
as well, because the shape description stores the type and thus the outcome of
the type check the guard does is statically known.

-In the example from last section, the following operations in the upper half
+In the example from Section~\ref{sub:example}, the following operations in the upper half
of Figure~\ref{fig:unopt-trace} produce two
static objects, and can be completely removed from the optimized trace:

@@ -737,8 +743,9 @@
In this section we want to give a formal description of the semantics of the
traces and of the optimizer and liken the optimization to partial evaluation.
We focus on the operations for manipulating dynamically allocated objects,
-as those are the only ones that are actually optimized. Without loss of
-generality we also consider only objects with two fields in this section.
+as those are the only ones that are actually optimized. We also consider only
+objects with two fields in this section, generalizing to arbitrary many fields
+is straightforward.

Traces are lists of operations. The operations considered here are
\lstinline{new}, \lstinline{get}, \lstinline{set} and \lstinline{guard_class}.
@@ -853,8 +860,8 @@

The static heap is a partial function from $V^*$ into the
set of static objects, which are triples of a type and two elements of $V^*$.
-A variable $v^*$ is in the domain of the static heap $S$ as long as the
-optimizer does not need to become dynamic XXX. The object $S(v^*)$ describes
+The object referenced by a variable $v^*$ is static, if $v^*$ is in the domain
+of the static heap $S$. The object $S(v^*)$ describes
what is statically known about the object, \ie its type and its fields. The
fields of objects in the static heap are also elements of $V^*$ (or null, for
short periods of time).