[pypy-commit] extradoc extradoc: write more about the low-level aspects of guards

[bivab]

Author: David Schneider <david.schneider at picle.org>
Branch: extradoc
Changeset: r4302:7b4066399558
Date: 2012-07-16 16:53 +0200
http://bitbucket.org/pypy/extradoc/changeset/7b4066399558/

Log:	write more about the low-level aspects of guards

diff --git a/talk/vmil2012/paper.tex b/talk/vmil2012/paper.tex
--- a/talk/vmil2012/paper.tex
+++ b/talk/vmil2012/paper.tex
@@ -102,7 +102,15 @@
 %___________________________________________________________________________
 \section{Introduction}
 
+In this paper we describe and analyze how deoptimization works in the context
+of tracing just-in-time compilers. What instructions are used in the
+intermediate and low-level representation of the JIT instructions and how these
+are implemented.
 
+Although there are several publications about tracing jut-in-time compilers, to
+our knowledge, there are none that describe the use and implementaiton of
+guards in this context. With the following contributions we aim to sched some
+light (to much?) on this topic.
 The contributions of this paper are:
 \begin{itemize}
  \item
@@ -120,14 +128,14 @@
 The RPython language and the PyPy Project were started in 2002 with the goal of
 creating a python interpreter written in a High level language, allowing easy
 language experimentation and extension. PyPy is now a fully compatible
-alternative implementation of the Python language, xxx mention speed. The
+alternative implementation of the Python language\bivab{mention speed}. The
 Implementation takes advantage of the language features provided by RPython
 such as the provided tracing just-in-time compiler described below.
 
 RPython, the language and the toolset originally developed to implement the
 Python interpreter have developed into a general environment for experimenting
-and developing fast and maintainable dynamic language implementations. xxx Mention
-the different language impls.
+and developing fast and maintainable dynamic language implementations.
+\bivab{Mention the different language impls}
 
 RPython is built of two components, the language and the translation toolchain
 used to transform RPython programs to executable units.  The RPython language
@@ -175,12 +183,58 @@
 \section{Guards in the Backend}
 \label{sec:Guards in the Backend}
 
-* Low level handling of guards
-   * Fast guard checks v/s memory usage
-   * memory efficient encoding of low level resume data
-   * fast checks for guard conditions
-   * slow bail out
+Code generation consists of two passes over the lists of instructions, a
+backwards pass to calculate live ranges of IR-level variables and a forward one
+to emit the instructions. During the forward pass IR-level variables are
+assigned to registers and stack locations by the register allocator according to
+the requirements of the to be emitted instructions. Eviction/spilling is
+performed based on the live range information collected in the first pass. Each
+IR instruction is transformed into one or more machine level instructions that
+implement the required semantics.  Guards instructions are transformed into
+fast checks at the machine code level that verify the corresponding condition.
+In cases the value being checked by the guard is not used anywhere else the
+guard and the operation producing the value can merged, reducing even more the
+overhead of the guard.
 
+Each guard in the IR has attached to it a list of the IR-variables required to
+rebuild the execution state in case the trace is left through the side-exit
+corresponding to the guard. When a guard is compiled, additionally to the
+condition check two things are generated/compiled. First a special
+data structure is created that encodes the information provided by the register
+allocator about where the values corresponding to each IR-variable required by
+the guard will be stored when execution reaches the code emitted for the
+corresponding guard. \bivab{go into more detail here?!} This encoding needs to
+be as compact as possible to maintain an acceptable memory profile.
+
+\bivab{example goes here}
+
+Second a trampoline method stub is generated. Guards are usually implemented as
+a conditional jump to this stub, jumping to in case the guard condition check
+does not hold and a side-exit should be taken. This stub loads the pointer to
+the encoding of the locations mentioned above, preserves the execution state
+(stack and registers) and then jumps to generic bail-out handler that is used
+to leave the compiled trace if case of a guard failure.
+
+Using the encoded location information the bail-out handler reads from the
+saved execution state the values that the IR-variables had  at the time of the
+guard failure and stores them in a location that can be read by the fronted.
+After saving the information the control is passed to the frontend signaling
+which guard failed so the frontend can read the information passed and restore
+the state corresponding to the point in the program.
+
+As in previous sections the underlying idea for the design of guards is to have
+a fast on trace profile and a potentially slow one in the bail-out case where
+the execution takes one of the side exits due to a guard failure. At the same
+time the data stored in the backend needed to rebuild the state should be be
+as compact as possible to reduce the memory overhead produced by the large
+number of guards\bivab{back this}.
+
+%* Low level handling of guards
+%   * Fast guard checks v/s memory usage
+%   * memory efficient encoding of low level resume data
+%   * fast checks for guard conditions
+%   * slow bail out
+%
 % section Guards in the Backend (end)
 
 %___________________________________________________________________________