cfbolz at codespeak.net cfbolz at codespeak.net
Fri Dec 19 15:59:27 CET 2008

Author: cfbolz
Date: Fri Dec 19 15:59:26 2008
New Revision: 60595

Modified:
Log:
some fixes

==============================================================================
+++ pypy/extradoc/talk/ecoop2009/intro.tex	Fri Dec 19 15:59:26 2008
@@ -86,7 +86,7 @@

The first step is to write an interpreter for the chosen language.  Since it
must be fed to the translation toolchain, the interpreter has to be written in
-RPython.  Then, to get best performances, we need to add few manual
+RPython.  Then, to guide the process, we need to add few manual
annotations to the interpreter, in order to teach the JIT generator which
informations are important to know at compile-time.  Annotations are inserted
as \emph{hints}, as described in section \ref{sec:hints}.
@@ -107,9 +107,6 @@
developer's machine.  By contrast, compile-time and runtime happens every time
the user wants to run some program.

-
-\subsection{Effective JIT compilation of dynamic languages}
-
Generating efficient compilers for dynamic languages is hard.  Since these
languages are dynamically typed, usually the compiler does not have enough
information to produce efficient code, but instead it has to insert a lot of
@@ -122,26 +119,31 @@

Most JIT compilers for dynamic languages around (such as IronPython, Jython,
JRuby \anto{XXX insert some reference}) compile code at the method
-granularity.  If on one hand they can exploit some of the knowledge gathered
+granularity.  If on the one hand they can exploit some of the knowledge gathered
at runtime (e.g. the types of method parameters), on the other hand they can
do little to optimize most of the operations inside, because their behaviour
depends on informations that are not available at compile-time, because
e.g. the global state of the program can change at runtime. \anto{e.g., we can
add/remove methods to classes, etc. Should we insert some example here?}
+\cfbolz{the last sentence is waaay too complicated}

JIT compilers generated by PyPy solve this problem by delaying the compilation
until they know all the informations needed to generate efficient code.  If at
some point the JIT compiler does not know about something it needs, it
-generates a callback into itself.
+generates a callback into itself and stops execution.

-Later, when the generated code is executed, the callback is hit and the JIT
+Later, when the generated code is executed, the callback might be hit and the JIT
compiler is restarted again.  At this point, the JIT knows exactly the state
of the program and can exploit all this extra knowledge to generate highly
efficient code.  Finally, the old code is patched and linked to the newly
generated code, so that the next time the JIT compiler will not be invoked
again.  As a result, \textbf{runtime and compile-time are continuously
-  intermixed}.
+interleaved}. The primitive to do this sort of interleaving is called promotion,
+it is described in Section \ref{sec:promotion}.
+
+One of the most important optimizations that the generated JIT does is removing
+unnecessary allocations. This is described in Section \ref{sec:virtuals}

-Modifying the old code to link the newly generated one is very challenging on
+Modifying the old code to link to the newly generated one is very challenging on
.NET, as the framework does not offer any primitive to do this.  Section
\ref{sec:clibackend} explains how it is possible to simulate this behaviour.

==============================================================================
+++ pypy/extradoc/talk/ecoop2009/jitgen.tex	Fri Dec 19 15:59:26 2008
@@ -267,6 +267,7 @@
This hint is a \emph{local} request for \texttt{v2} to be green, without
requiring \texttt{v1} to be green.  Note that this amounts to copying
a red value into a green one, which is not possible in classical
-approaches to partial evaluation.  See the Promotion section XXX ref for a
+approaches to partial evaluation.  See Section \ref{sec:promotion} for a
complete discussion of promotion.

+