[pypy-commit] extradoc extradoc: First-step planning.
noreply at buildbot.pypy.org
Tue Jan 31 18:57:10 CET 2012
Author: Armin Rigo <arigo at tunes.org>
Date: 2012-01-31 18:56 +0100
Log: First-step planning.
diff --git a/planning/stm.txt b/planning/stm.txt
@@ -2,6 +2,9 @@
+Comments in << >> describe the next thing to work on.
@@ -72,6 +75,9 @@
use 4-5 bits, where in addition we use some "thread hash" value if there
is only one copy.
+<< NOW: think of a minimal GC model with these properties. We probably
+need GC_GLOBAL, a single bit of GC_WAS_COPIED, and the version number. >>
@@ -96,6 +102,10 @@
depending on cases). And if the read is accepted then we need to
remember in a local list that we've read that object.
+<< NOW: implement the thread's local dictionary in C, as say a search
+tree. Should be easy enough if we don't try to be as efficient as
+possible. The rest of the logic here is straightforward. >>
@@ -114,6 +124,8 @@
consistent copy (i.e. nobody changed the object in the middle of us
reading it). If it is too recent, then we might have to abort.
+<< NOW: straightforward >>
@@ -132,6 +144,9 @@
We need to check that each of these global objects' versions have not
been modified in the meantime.
+<< NOW: should be easy, but with unclear interactions between the C
+code and the GC. >>
@@ -149,6 +164,8 @@
of a localobj are themselves localobjs. This would be useful for
'PyFrame.fastlocals_w': it should also be known to always be a localobj.
+<< do later >>
@@ -173,6 +190,9 @@
all global reads done --- "compress" in the sense of removing
+<< do later; memory usage grows unboundedly during one transaction for
@@ -218,6 +238,10 @@
* Parallelism: there are multiple threads all doing something GC-related,
like all scanning the heap together.
+<< at first the global area keeps growing unboundedly. The next step
+will be to add the LIL but run the global collection by keeping all
+other threads blocked. >>
When not running transactively
@@ -240,11 +264,11 @@
is called, we can try to do such a collection, but what about the pinned
-Some intermediate solution would be to let this mode be rather slow:
+<< NOW: let this mode be rather slow. To implement this mode, we would
have only global objects, and have the stm_write barrier of 'obj' return
-'obj'. Do only global collections. Allocation would allocate
-immediately a global object, mostly without being able to benefit from
+'obj'. Do only global collections (one we have them; at first, don't
+collect at all). Allocation would allocate immediately a global object,
+without being able to benefit from bump-pointer allocation. >>
@@ -261,6 +285,8 @@
dictionary if they map to each other. And we need to take care of the
cases of NULL pointers.
+<< NOW: straightforward, if we're careful not to forget cases >>
More information about the pypy-commit