[pypy-svn] extradoc extradoc: some changes, some comments

[pedronis]

Author: Samuele Pedroni <pedronis at lucediurna.net>
Branch: extradoc
Changeset: r3425:09db589db4af
Date: 2011-03-27 18:53 +0200
http://bitbucket.org/pypy/extradoc/changeset/09db589db4af/

Log:	some changes, some comments

diff --git a/talk/icooolps2011/paper.tex b/talk/icooolps2011/paper.tex
--- a/talk/icooolps2011/paper.tex
+++ b/talk/icooolps2011/paper.tex
@@ -52,6 +52,7 @@
 \newcommand\anto[1]{\nb{ANTO}{#1}}
 \newcommand\arigo[1]{\nb{AR}{#1}}
 \newcommand\fijal[1]{\nb{FIJAL}{#1}}
+\newcommand\pedronis[1]{\nb{PEDRONIS}{#1}}
 \newcommand{\commentout}[1]{}
 
 \newcommand\ie{i.e.,\xspace}
@@ -104,12 +105,12 @@
 optimize its object model. This is made harder by the fact that many recent
 languages such as Python, JavaScript or Ruby have rather complex core object
 semantics. For them, implementing just an interpreter is already an arduous
-task. Implementing them efficiently with a just-in-time compiler is
-nigh-impossible, because or their many corner-cases.
+\pedronis{XXX ardous seems a bit too strong} task. Implementing them efficiently with a just-in-time compiler (JIT) is
+extremely challenging, because or their many corner-cases.
 
 It has long been an objective of the partial evaluation community to
 automatically produce compilers from interpreters. There has been a recent
-renaissance of this idea using the different technique of tracing just-in-time
+renaissance of this idea around the approach of tracing just-in-time
 compilers. A number of projects have attempted this approach. SPUR \cite{bebenita_spur:_2010} is
 a tracing JIT for .NET together with a JavaScript implementation in C\#. PyPy
 \cite{armin_rigo_pypys_2006} contains a tracing JIT for RPython (a restricted
@@ -119,9 +120,9 @@
 on and optimized with a tracing JIT for JavaScript
 \cite{yermolovich_optimization_2009}.
 
-These projects have in common that they implement a dynamic language in some
-implementation language. In addition they build a tracing JIT for that implementation
-language. The tracing JIT then traces through the object model of the dynamic
+These projects have in common that they work one meta-level down, providing a tracing JIT for the implementation
+language used to implement the dynamic language, and not for the dynamic language itself.
+The tracing JIT then will trace through the object model of the dynamic
 language implementation. This makes the object model transparent to the tracer
 and its optimizations. Therefore the semantics of the dynamic language does not
 have to be replicated in a JIT. We call this approach \emph{meta-tracing}.
@@ -195,7 +196,7 @@
 \label{sub:tracing}
 
 A recently popular approach to JIT compilers is that of tracing JITs. Tracing
-JITs have their origin in the Dynamo project which used the for dynamic
+JITs have their origin in the Dynamo project which used them for dynamic
 assembler optimization \cite{bala_dynamo:_2000}. Later they were used for to implement
 a lightweight JIT for Java \cite{gal_hotpathvm:_2006} and for dynamic languages such as
 JavaScript \cite{gal_trace-based_2009}.
@@ -217,8 +218,7 @@
 Because the traces always correspond to a concrete execution they cannot
 contain any control flow splits. Therefore they encode the control flow
 decisions needed to stay on the trace with the help of \emph{guards}. Those are
-operations that check that the assumptions are still true when the trace is
-later executed with different values.
+operations that check that the assumptions are still true when the compiled trace is later executed with different values.
 
 One disadvantage of tracing JITs which makes them not directly applicable to
 PyPy is that they need to encode the language semantics of the language they are
@@ -249,7 +249,7 @@
 \end{figure}
 
 Figure~\ref{fig:trace-levels} shows a diagram of the process. On the left you
-see the levels of execution. The CPU executes the binary of
+\pedronis{XXX style: do we want to use you, or we and one} see the levels of execution. The CPU executes the binary of
 PyPy's Python interpreter, which consists of RPython functions that have been
 compiled first to C, then to machine code. The interpreter runs a Python program written by a
 programmer (the user). If the tracer is used, it traces operations on the level
@@ -706,7 +706,7 @@
 Every time the class changes, \texttt{find\_method} can potentially return a
 new value.
 
-Therefore, we give every class a version number, which is changed every time a
+Therefore, we give every class a version object, which is changed every time a
 class gets changed (i.e., the content of the \texttt{methods} dictionary changes).
 This means that the result of \texttt{methods.get()} for a given \texttt{(name,
 version)} pair will always be the same, i.e. it is a pure operation.  To help

diff --git a/talk/icooolps2011/jit-hints.pdf b/talk/icooolps2011/jit-hints.pdf
index d36331dd7582c79fa5ddda451e9e9eab656ca51c..91b5aa6d7e372b1f8874c7a9754f583856469075
GIT binary patch
[cut]