Author: David Schneider <david.schnei...@picle.org> Branch: extradoc Changeset: r4394:c8a4351eca43 Date: 2012-07-30 15:52 +0200 http://bitbucket.org/pypy/extradoc/changeset/c8a4351eca43/
Log: more related work diff --git a/talk/vmil2012/paper.bib b/talk/vmil2012/paper.bib --- a/talk/vmil2012/paper.bib +++ b/talk/vmil2012/paper.bib @@ -1,3 +1,14 @@ +@inproceedings{Gal:2006, + author = {Gal, Andread and Probst, Christian W. and Franz, Michael}, + title = {{HotpathVM: An Effective JIT Compiler for Resource-constrained Devices}}, + location = {Ottawa, {Ontario}, {Canada}}, + series = {{VEE} '06}, + isbn = {1-59593-332-6}, + booktitle = {Proceedings of the 2nd International Conference on Virtual Execution Environments}, + publisher = {{ACM}}, + year = {2006}, + pages = {144-153} +} @inproceedings{Gal:2009ux, author = {Gal, Andreas and Franz, Michael and Eich, B and Shaver, M and Anderson, David}, title = {{Trace-based Just-in-Time Type Specialization for Dynamic Languages}}, @@ -9,5 +20,11 @@ title = {{Dynamo: A Transparent Dynamic Optimization System}}, booktitle = {PLDI '00: Proceedings of the ACM SIGPLAN 2000 conference on Programming language design and implementation}, } +@misc{Pall:2009, + author = {Pall, Mike}, + title = {LuaJIT 2.0 intellectual property disclosure and research opportunities}, + month = jun, + year = {2009}, + url = {http://lua-users.org/lists/lua-l/2009-11/msg00089.html} +} - diff --git a/talk/vmil2012/paper.tex b/talk/vmil2012/paper.tex --- a/talk/vmil2012/paper.tex +++ b/talk/vmil2012/paper.tex @@ -517,9 +517,7 @@ \label{fig:benchmarks} \end{figure*} -\todo{resume data size estimates on 64bit} \todo{figure about failure counts of guards (histogram?)} -\todo{integrate high level resume data size into Figure \ref{fig:backend_data}} \todo{add resume data sizes without sharing} \todo{add a footnote about why guards have a threshold of 100} @@ -553,6 +551,9 @@ \subsection{Guards in Other Tracing JITs} \label{sub:Guards in Other Tracing JITs} +Guards as described are a concept associated with tracing just-in-time +compilers to represent possible divergent control flow paths. + SPUR~\cite{bebenita_spur:_2010} is a tracing JIT compiler for a C\# virtual machine. It handles guards by always generating code for every one of them @@ -561,13 +562,42 @@ of the unoptimized code, the transfer code is quite large. -\bivab{mention Gal et al.~\cite{Gal:2009ux} trace stitching} -and also mention \bivab{Dynamo's fragment linking~\cite{Bala:2000wv}} in -relation to the low-level guard handling. +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 +LuaJIT~\cite{Pall:2009}.\todo{decide if LuaJIT is a footnote or a reference and +fix website citation} Pall explains that guards in LuaJIT use a datastucture +called snapshots, similar to PyPy's resume data, to store the information about +how to rebuild the state from a side-exit using the information in the snapshot +and the machine execution state. Pall also acknowledges that snapshot for +guards are associated with a large memory footprint. The solution used in +LuaJIT is to store sparse snapshots, avoiding the creation of snapshots for +every guard to reduce memory pressure. Snapshots are only created for guards +after updates to the global state, after control flow points from the original +program and for guards that are likely to fail. As an outlook Pall mentions the +plans to switch to compressed snapshots to further reduce redundancy. -\todo{look into tracing papers for information about guards and deoptimization} -LuaJIT \todo{link to mailing list discussion} -http://lua-users.org/lists/lua-l/2009-11/msg00089.html +Linking side exits to pieces of later compiled machine code was described first +in the context of Dynamo~\cite{Bala:2000wv} under the name of Fragment Linking. +Once a new hot trace is emitted into the fragment cache it is linked to side +exit that led to the compilation. Fragment Linking avoids the performance +penalty involved in leaving the compiled and it to remove the compensation +code used when restoring the machine state on a side exit. + +In~\cite{Gal:2006} Gal et. al describe that in the HotpathVM 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 generting 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 +and variables. + +Gal et. al~\cite{Gal:2009ux} write about how TraceMonkey uses trace stitching +to avoid th overhead of returning to the trace monitor and calling another +trace when taking a side exit. In their approach it is required to write live +values to an activation record before entering the new trace. % subsection Guards in Other Tracing JITs (end) _______________________________________________ pypy-commit mailing list pypy-commit@python.org http://mail.python.org/mailman/listinfo/pypy-commit