[pypy-commit] extradoc extradoc: Update the status.
noreply at buildbot.pypy.org
Sat Feb 25 20:08:55 CET 2012
Author: Armin Rigo <arigo at tunes.org>
Date: 2012-02-25 20:08 +0100
Log: Update the status.
diff --git a/planning/stm.txt b/planning/stm.txt
@@ -75,8 +75,8 @@
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. >>
+<< NOW: implemented a minimal GC model with these properties. We have
+GC_GLOBAL, a single bit of GC_WAS_COPIED, and the version number. >>
@@ -102,9 +102,8 @@
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. >>
+<< NOW: the thread's local dictionary is in C, as a search tree.
+The rest of the logic here is straightforward. >>
@@ -124,7 +123,7 @@
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 >>
+<< NOW: done, straightforward >>
TODO: how do we handle MemoryErrors when making a local copy??
Maybe force the transaction to abort, and then re-raise MemoryError
@@ -147,8 +146,7 @@
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. >>
+<< NOW: done, kind of easy >>
@@ -167,7 +165,10 @@
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 >>
+<< NOW: done in the basic form by translator/stm/transform.py.
+Runs late (just before C databasing). Should work well enough to
+remove the maximum number of write barriers, but still missing
@@ -243,7 +244,9 @@
<< 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. >>
+other threads blocked. NOW: think about, at least, doing "minor
+collections" on the global area *before* we even start running
When not running transactively
@@ -267,19 +270,10 @@
is called, we can try to do such a collection, but what about the pinned
-<< NOW: let this mode be rather slow. Two solutions are considered:
- 1. we would have only global objects, and have the stm_write barrier
- of 'obj' return 'obj'. Do only global collections (once 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.
- 2. allocate in a nursery, never collected for now; but just do an
- end-of-transaction collection when transaction.run() is first
+<< NOW: the global area is just the "nursery" for the main thread.
+stm_writebarrier of 'obj' return 'obj' in the main thread. All
+allocations get us directly a global object, but allocated from
+the "nursery" of the main thread, with bump-pointer allocation. >>
@@ -296,8 +290,11 @@
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 >>
+<< NOW: done, without needing the local dictionary:
+stm_normalize_global(obj) returns globalobj if obj is a local,
+WAS_COPIED object. Then a pointer comparison 'x == y' becomes
+stm_normalize_global(x) == stm_normalize_global(y). Moreover
+the call to stm_normalize_global() can be omitted for constants. >>
More information about the pypy-commit