Author: Armin Rigo <[email protected]> Branch: extradoc Changeset: r4070:9e7b09df3f36 Date: 2012-01-31 18:56 +0100 http://bitbucket.org/pypy/extradoc/changeset/9e7b09df3f36/
Log: First-step planning. diff --git a/planning/stm.txt b/planning/stm.txt --- a/planning/stm.txt +++ b/planning/stm.txt @@ -2,6 +2,9 @@ STM planning ============ +Comments in << >> describe the next thing to work on. + + Overview -------- @@ -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. >> + stm_read -------- @@ -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. >> + stm_write --------- @@ -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 >> + End-of-transaction collections ------------------------------ @@ -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. >> + Annotator support ----------------- @@ -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 >> + Local collections ----------------- @@ -173,6 +190,9 @@ all global reads done --- "compress" in the sense of removing duplicates. +<< do later; memory usage grows unboundedly during one transaction for +now. >> + Global collections ------------------ @@ -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 objects? -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 -bump-pointer allocation. +'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. >> Pointer equality @@ -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 >> + _______________________________________________ pypy-commit mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-commit
