[pypy-svn] extradoc extradoc: vague first draft of some of the related work parts

Sun Mar 27 15:59:02 CEST 2011

Author: Carl Friedrich Bolz <cfbolz at gmx.de>
Branch: extradoc
Changeset: r3423:c264c1dfa8fb
Date: 2011-03-27 15:58 +0200
http://bitbucket.org/pypy/extradoc/changeset/c264c1dfa8fb/

Log:	vague first draft of some of the related work parts

diff --git a/talk/icooolps2011/paper.tex b/talk/icooolps2011/paper.tex
--- a/talk/icooolps2011/paper.tex
+++ b/talk/icooolps2011/paper.tex
@@ -5,6 +5,7 @@
 \usepackage{color}
 \usepackage{ulem}
 \usepackage{xspace}
+\usepackage{relsize}
 \usepackage{epsfig}
 \usepackage{amssymb}
 \usepackage{amsmath}
@@ -814,13 +815,52 @@
 
 \section{Related Work}
 
-partial evaluation \cite{futamura_partial_1999} \cite{jones_partial_1993}
+The very first meta-tracer is described by Sullivan et. al.
+\cite{sullivan_dynamic_2003}. They used Dynamo RIO, the successor of Dynamo
+\cite{XXX} to trace through a small synthetic interpreter. As in Dynamo, tracing
+happens on the machine code level. The tracer is instructed by some hints in the
+tiny interpreter where the main interpreter loop is and for how long to trace to
+match loops in the user-level functions. These hints are comparable to the one
+PyPy uses for the same reasons \cite{bolz_tracing_2009}. Their approach suffers
+mostly from the low abstraction level that machine code provides.
 
-earlier examples of promotion \cite{carl_friedrich_bolz_towards_????}, \cite{armin_rigo_jit_2007}
+Yermolovich et. al. describe the use of the Tamarin JavaScript tracing JIT as a
+meta-tracer for a Lua interpreter. They compile the normal Lua interpreter in C
+to ActionScript bytecode. Again, the interpreter is annotated with some hints
+that indicate the main interpreter loop to the tracer.  No further hints are
+described in the paper. There is no comparison of their system to the original
+Lua VM in C, which makes it hard to judge the effectiveness of the approach.
 
-meta-tracers: SPUR \cite{bebenita_spur:_2010}
-tamarin/lua stuff \cite{yermolovich_optimization_2009}
-Dynamo \cite{sullivan_dynamic_2003}
+SPUR \cite{bebenita_spur:_2010} is a tracing JIT for CIL bytecode, which is then
+used to trace through an JavaScript implementation written in C\#. The
+JavaScript implementation compiles JavaScript to CIL bytecode together with an
+implementation of the JavaScript object model. The object model uses maps
+and inline caches to speed up operations on objects. The tracer tracers through
+the compiled JavaScript functions and the object model. SPUR contains two hints
+that can be used to influence the tracer, one to prevent tracing of a C\#
+function and one to force unrolling of a loop (PyPy has equivalent hints, but
+they were not described in this paper).
+
+
+Partial evaluation \cite{jones_partial_1993} tries to automatically transform
+interpreters into compilers using the second futamura projection
+\cite{futamura_partial_1999}. XXX
+
+An early attempt at building a general environment for implementing languages
+efficiently is described by Wolczko et. al. \cite{mario_wolczko_towards_1999}.
+They implement Java and Smalltalk on top of the SELF VM by compiling the
+languages to SELF. The SELF JIT is good enough to optimize the compiled code
+very well. We believe the approach to be restricted to languages that are
+similar enough to SELF. XXX
+
+Somewhat relatedly, the proposed ``invokedynamic'' bytecode
+\cite{rose_bytecodes_2009} that will be added to the JVM is supposed to make the
+implementation of dynamic languages on top of JVMs easier. The bytecode gives
+the language implementor control over how the JIT optimizes the language's
+features. XXX
+
+%We already explored promotion in other context, such as earlier examples of
+%promotion \cite{carl_friedrich_bolz_towards_????}, \cite{armin_rigo_jit_2007}
 
 \cite{chambers_efficient_1989} maps
 \cite{hoelzle_optimizing_1994} Type feedback
@@ -834,10 +874,6 @@
 
 jruby used versions at some point, jvm-l mailing list discusses them
 
-\cite{mario_wolczko_towards_1999}
-
-invokedynamic tries to give control to the language implementor about PICs and
-deoptimization
 
 \section{Conclusion and Next Steps}
 

diff --git a/talk/icooolps2011/paper.bib b/talk/icooolps2011/paper.bib
--- a/talk/icooolps2011/paper.bib
+++ b/talk/icooolps2011/paper.bib
@@ -152,6 +152,21 @@
 	pages = {465{\textendash}478}
 },
 
+ at article{rose_bytecodes_2009,
+	series = {{VMIL} '09},
+	title = {Bytecodes meet combinators: invokedynamic on the {JVM}},
+	location = {Orlando, Florida},
+	shorttitle = {Bytecodes meet combinators},
+	doi = {10.1145/1711506.1711508},
+	abstract = {The Java Virtual Machine {(JVM)} has been widely adopted in part because of its classfile format, which is portable, compact, modular, verifiable, and reasonably easy to work with. However, it was designed for just one {language---Java---and} so when it is used to express programs in other source languages, there are often "pain points" which retard both development and execution. The most salient pain points show up at a familiar place, the method call site. To generalize method calls on the {JVM,} the {JSR} 292 Expert Group has designed a new invokedynamic instruction that provides user-defined call site semantics. In the chosen design, invokedynamic serves as a hinge-point between two coexisting kinds of intermediate language: bytecode containing dynamic call sites, and combinator graphs specifying call targets. A dynamic compiler can traverse both representations simultaneously, producing optimized machine code which is the seamless union of both kinds of input. As a final twist, the user-defined linkage of a call site may change, allowing the code to adapt as the application evolves over time. The result is a system balancing the conciseness of bytecode with the dynamic flexibility of function pointers.},
+	journal = {Proceedings of the Third Workshop on Virtual Machines and Intermediate Languages},
+	author = {John R Rose},
+	year = {2009},
+	note = {{ACM} {ID:} 1711508},
+	keywords = {bytecode, code generation, combinator},
+	pages = {2:1{\textendash}2:11}
+},
+
 @article{bolz_allocation_2011,
 	series = {{PEPM} '11},
 	title = {Allocation removal by partial evaluation in a tracing {JIT}},
@@ -298,6 +313,17 @@
 	pages = {1--12}
 },
 
+ at techreport{andreas_gal_incremental_2006,
+	title = {Incremental Dynamic Code Generation with Trace Trees},
+	abstract = {The unit of compilation for traditional just-in-time compilers is the method. We have explored trace-based compilation, in which the unit of compilation is a loop, potentially spanning multiple methods and even library code. Using a new intermediate representation that is discovered and updated lazily on-demand while the program is being executed, our compiler generates code that is competitive with traditional dynamic compilers, but that uses only a fraction of the compile time and memory footprint.},
+	number = {{ICS-TR-06-16}},
+	institution = {Donald Bren School of Information and Computer Science, University of California, Irvine},
+	author = {Andreas Gal and Michael Franz},
+	month = nov,
+	year = {2006},
+	pages = {11}
+},
+
 @inproceedings{gal_hotpathvm:_2006,
 	address = {Ottawa, Ontario, Canada},
 	title = {{HotpathVM:} an effective {JIT} compiler for resource-constrained devices},
@@ -346,7 +372,13 @@
 	isbn = {978-1-60558-769-1},
 	url = {http://portal.acm.org/citation.cfm?id=1640134.1640147},
 	doi = {10.1145/1640134.1640147},
-	abstract = {Creating an interpreter is a simple and fast way to implement a dynamic programming language. With this ease also come major drawbacks. Interpreters are significantly slower than compiled machine code because they have a high dispatch overhead and cannot perform optimizations. To overcome these limitations, interpreters are commonly combined with just-in-time compilers to improve the overall performance. However, this means that a just-in-time compiler has to be implemented for each language.},
+	abstract = {Creating an interpreter is a simple and fast way to implement a dynamic programming language. With this ease also come major drawbacks. Interpreters are significantly slower than compiled machine code because they have a high dispatch overhead and cannot perform optimizations. To overcome these limitations, interpreters are commonly combined with just-in-time compilers to improve the overall performance. However, this means that a just-in-time compiler has to be implemented for each language.
+
+We explore the approach of taking an interpreter of a dynamic 
+language and running it on top of an optimizing trace-based virtual machine, i.e., we run a guest {VM} on top of a host {VM.} The host {VM} uses trace recording to observe the guest {VM} executing the application program. Each recorded trace represents a sequence
+of guest {VM} bytecodes corresponding to a given execution path
+through the application program. The host {VM} optimizes and compiles these traces to machine code, thus eliminating the need for a custom just-in-time compiler for the guest {VM.} The guest {VM} only needs to provide basic  information about its interpreter loop to the
+host {VM.}},
 	booktitle = {Proceedings of the 5th symposium on Dynamic languages},
 	publisher = {{ACM}},
 	author = {Alexander Yermolovich and Christian Wimmer and Michael Franz},
