[pypy-svn] r69638 - pypy/branch/virtual-forcing/pypy/jit/metainterp/doc
arigo at codespeak.net
arigo at codespeak.net
Wed Nov 25 17:20:17 CET 2009
Date: Wed Nov 25 17:20:17 2009
New Revision: 69638
Delete and simplify the "explanations" here. Should be killed at some
point, and written down as real documentation.
--- pypy/branch/virtual-forcing/pypy/jit/metainterp/doc/jitpl5.txt (original)
+++ pypy/branch/virtual-forcing/pypy/jit/metainterp/doc/jitpl5.txt Wed Nov 25 17:20:17 2009
@@ -78,16 +78,11 @@
matches the real data -- but this is delicate because of the
-Instead, this is done by doing tracing from the start of the loop again.
-At the end, we don't do perfect specialization (for now), but simply
-check that the already-computed specialization still applies, and then
-jump to the already-compiled loop. (If it does not match, for now we
-just cancel everything.)
-If the loop is not only executed but *entered* often enough, then after
-this tracing, we generate a second copy of the loop (a "bridge") that
-starts with all variables unspecialized, and ends with a jump to the
-real loop. From this point on, we can just jump directly to the bridge
+Instead, this is done by "entry bridges": we do tracing from
+the start of the loop again, and at the end, we try to compile
+the recorded trace as a "bridge" that comes from the
+interpreter (i.e. with no virtuals at all) and goes to the old
+loop. Later on, we can just jump directly to the entry bridge
from the JUMP_ABSOLUTE bytecode.
@@ -105,10 +100,7 @@
take the set of live values and put them back into boxes, and proceed
with tracing for the rest of the loop.
-For now, we just check at the end of the loop that it matches the
-already-computed specialization. If not, we cancel creating the
-compiled version of it (and mark the guard so that future failures
-always fall back to interpretation). To do this, when we created the
-original loop, at every guard, we needed to record the set of live
-values (mostly in which register or stack location they are) as well as
-an "escaped-so-far" flag for each pointer.
+At the end of the loop, we check that it matches an already-computed
+specialization. If not, we go on tracing. This might unroll the loop
+once. (Note that there is a global limit on the length of the recorded
+trace, to avoid tracing forever.)
--- pypy/branch/virtual-forcing/pypy/jit/metainterp/doc/loop.txt (original)
+++ pypy/branch/virtual-forcing/pypy/jit/metainterp/doc/loop.txt Wed Nov 25 17:20:17 2009
@@ -36,32 +36,11 @@
. VirtualSpec(cls, name1=spec1, ...)
- VirtualizableSpec(cls, name1=spec1, ...)
-For (a simplified) example, ``VirtualizableSpec(PyFrame, x =
-VirtualSpec(W_IntObject, value = NotSpec))`` describes the virtualizable
-frame for a loop in which the only used variable is ``x``, which is a
-The intersection rules are:
-* the intersection of two ``VirtualSpec`` of the same ``cls`` is a
- further ``VirtualSpec``, and we proceed with the intersection of
- each field.
-* the intersection of two ``VirtualizableSpec`` of the same ``cls`` is
- like the previous case, except that some names may be omitted
- completely from a given ``VirtualizableSpec``; in the case a name is
- present in only one of the ``VirtualizableSpec``, we just keep it
- unmodified in the intersection.
-* in other cases, the result is ``FixedClassSpec`` if the two specnodes
- have the same class, or ``NotSpec`` if any is a ``NotSpec`` or if the
- two classes differ.
+For example, ``VirtualSpec(W_IntObject, value = NotSpec))`` describes a
+variable which is a virtual ``W_IntObject``, containing a value that is
+a real integer.
More information about the Pypy-commit