[pypy-commit] extradoc extradoc: safe some lines

[cfbolz]

Author: Carl Friedrich Bolz <cfbolz at gmx.de>
Branch: extradoc
Changeset: r4780:549bf37193af
Date: 2012-09-07 11:41 +0200
http://bitbucket.org/pypy/extradoc/changeset/549bf37193af/

Log:	safe some lines

diff --git a/talk/vmil2012/paper.tex b/talk/vmil2012/paper.tex
--- a/talk/vmil2012/paper.tex
+++ b/talk/vmil2012/paper.tex
@@ -513,6 +513,7 @@
 
 \begin{figure}[ht]
 \includegraphics[width=0.4\textwidth]{figures/resume_data.pdf}
+\vspace{-3mm}
 \caption{The resume data for Figure~\ref{fig:trace-log}}
 \label{fig:resume-data}
 \end{figure}
@@ -861,7 +862,7 @@
 that transfers control back to the unoptimized code.
 Since the transfer code needs to reconstruct the stack frames
 of the unoptimized code,
-the transfer code is quite large.
+the transfer code is large.
 
 Mike Pall, the author of LuaJIT describes in a post to the lua-users mailing
 list different technologies and techniques used in the implementation of
@@ -887,15 +888,15 @@
 also allows to remove compensation code associated to the linked fragments that
 would have been required to restored the execution state on the side exit.
 
-Gal et. al~\cite{Gal:2006} describe how in the HotpathVM, a JIT for a Java VM, they experimented
+Gal et. al~\cite{Gal:2006} describe the HotpathVM, a JIT for a Java VM. They experimented
 with having one generic compensation code block, like the RPython JIT, that
 uses a register variable mapping to restore the interpreter state. Later this
 was replaced by generating compensation code for each guard which produced a
 lower overhead in their benchmarks. HotpathVM also records secondary traces
 starting from failing guards that are connected directly to the original trace.
 Secondary traces are compiled by first restoring the register allocator state to
-the state at the side exit. The information is retrieved from a mapping stored
-in the guard that maps machine level registers and stack to Java level stack
+the state at the side exit. The information is a mapping stored
+in the guard between machine level registers and stack to Java level stack
 and variables.
 
 For TraceMonkey, a tracing JIT for JavaScript, Gal et. al~\cite{Gal:2009ux}
@@ -912,11 +913,11 @@
 \label{sub:Deoptimization in Method-Based JITs}
 
 Deoptimization in method-based JITs is used if one of the assumptions
-of the code generated by a JIT-compiler changes.
+of the code generated by a JIT changes.
 This is often the case when new code is added to the system,
 or when the programmer tries to debug the program.
 
-Deutsch et. al.~\cite{deutsch_efficient_1984} describe the use of stack descriptions
+Deutsch et. al.~\cite{deutsch_efficient_1984} use stack descriptions
 to make it possible to do source-level debugging of JIT-compiled code.
 Self uses deoptimization to reach the same goal~\cite{holzle_debugging_1992}.
 When a function is to be debugged, the optimized code version is left
@@ -925,7 +926,7 @@
 that need to be re-created when leaving the optimized code.
 The scope descriptors are between 0.42 and 1.09 times
 the size of the generated machine code.
-All the information needed for debugging together
+The information needed for debugging together
 is between 1.22 and 2.33 times the size of generated machine code,
 according to the paper.
 
@@ -977,7 +978,7 @@
 that they do not fail often, we described how they have been implemented in the
 high- and low-level components of RPython's tracing JIT compiler.
 
-Additionally we have presented experimental data collected using the standard PyPy
+Additionally we presented experimental data collected using the standard PyPy
 benchmark set to evaluate previous observations and assumptions about guards. Our
 experiments confirmed that guards are a very common
 operation in traces. At the same time guards are associated with a high