[pypy-svn] r72332 - pypy/extradoc/talk/oopsla2010

[fijal at codespeak.net]

Author: fijal
Date: Wed Mar 17 19:45:50 2010
New Revision: 72332

Added:
   pypy/extradoc/talk/oopsla2010/paper2.txt   (contents, props changed)
Log:
Start writing down a paper, second approach


Added: pypy/extradoc/talk/oopsla2010/paper2.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/talk/oopsla2010/paper2.txt	Wed Mar 17 19:45:50 2010
@@ -0,0 +1,57 @@
+Problem domain
+==============
+
+Python, as well as other dynamic languages to varying extend, provides a way
+to dynamically introspect the frame stack of running program. The dynamism
+of Python language makes it impossible to statically detect all the cases
+in which a program can introspect the framestack. Most operations can
+execute arbitrary python code (including frame introspection code) and
+types are not known until runtime. XXX cite brett cannon about localized
+type inference.
+
+The nature of the way how the framestack is exposed, makes it impossible to
+perform common optimizations, like escape analysis (all local variables escape
+through frame object) or inlining (all frames are required to be present on
+framestack).
+
+Idea
+====
+
+In this paper we present a way to use the processor (or C) stack together
+with bookkeeping information that can lazily reconstruct the python framestack
+from processor stack, preserving all the necessary information. Our approach
+assumes that we have both the just in time compiler that compiles efficient
+code, that can fall back to interpreter in case of frame forcing. In theory,
+this approach can be implemented also with static compilation of python
+language, but the duality of efficiently compiled and interpreted (or much
+less efficiently compiled) needs to be preserved. The whole idea revolves
+around three basic concepts:
+
+* Virtualizables - frames that are allocated on the heap, but have fields
+  living on the processor stack that are lazily moved over to heap in case
+  of a direct access. This means even though frames has to be allocated,
+  they don't present any further overhead.
+
+* Virtual frames - frames that are known not to escape, except via framestack
+  (special objects called virtual refs explained below). They present no
+  overhead.
+
+* Virtual refs - special objects that can reference frames without escaping
+  them, used for frame chaining.
+
+We present benchmarks for both the small toy language that presents frame
+introspection capabilities as well as results for the python language.
+
+Our work revolves primarily around tracing just in time compiler infrastructure,
+that we wrote (XXX cite). While the idea is not tied directly to the JIT,
+it feels far more natural due to the dual-nature of compiler (JIT-compiled
+efficient code and fully frame-aware, much slower interpreter). There are
+other reasons why we chose JIT, notably the fact that inlining in static setting
+is proven to be very hard for the Python language (since anyone can change
+global namespace via which function objects are referenced).
+
+Benchmarks
+==========
+
+XXX actually write down the toy languages
+