[pypy-svn] r65549 - pypy/branch/pyjitpl5-experiments/pypy/jit/metainterp/doc

benjamin at codespeak.net benjamin at codespeak.net
Wed Jun 3 03:38:57 CEST 2009


Author: benjamin
Date: Wed Jun  3 03:38:55 2009
New Revision: 65549

Modified:
   pypy/branch/pyjitpl5-experiments/pypy/jit/metainterp/doc/virtualizables.txt
Log:
edits

Modified: pypy/branch/pyjitpl5-experiments/pypy/jit/metainterp/doc/virtualizables.txt
==============================================================================
--- pypy/branch/pyjitpl5-experiments/pypy/jit/metainterp/doc/virtualizables.txt	(original)
+++ pypy/branch/pyjitpl5-experiments/pypy/jit/metainterp/doc/virtualizables.txt	Wed Jun  3 03:38:55 2009
@@ -18,7 +18,7 @@
 object) which is stored on a framestack and allocated before each next
 call to portal (portal is a bytecode dispatch loop). Almost everything
 is stored on top of this virtualizable. There is a valuestack and locals
-which usually store most commonly accessed variables.
+which usually are most commonly accessed fields.
 
 A typical loop, for example for adding integers (the best benchmark ever)
 will look like this:
@@ -66,7 +66,7 @@
 stack or not allocated at all?
 
 1. We store a small piece of assembler code as a function pointer inside
-   a virtualizable. This is I think simpler than having complex rebuild
+   a virtualizable. This is, I think, simpler than having complex rebuild
    info kept together along the chain. If someone accesses the frame,
    this code will run and rebuild what is necessary. If this happens, there
    are two possiblities:



More information about the Pypy-commit mailing list