Sun Mar 27 18:53:26 CEST 2011

Author: Samuele Pedroni <pedronis at lucediurna.net>
Changeset: r3425:09db589db4af
Date: 2011-03-27 18:53 +0200

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]