The essential MPS concepts for GC are:
The advanced MPS concepts for GC are:
+The client can choose how to format its objects, but the MPS will sometimes need to ask the client some questions about an object, such @@ -181,12 +189,183 @@ AMCFix() (and now AMCHeaderFix() too).
It's a bit messy -- sorry.
+ +The client should:
+mps_reserve some memory,mps_commit the new object to MPS management.The MPS is a moving garbage collector: it supports + preserve-by-copying pools, whose objects are 'mobile'. + Whenever the MPS moves an object, it will ensure that + all managed references are updated to point to the + new location -- and this happens instantaneously as far + as the client sees it.
+ +The client should assume that, between any pair of + instructions, the MPS may 'shake' this graph, moving + all the mobile objects, and updating all the managed + references.
+ +The client usually takes care to ensure that the + references it + holds are managed. To be managed, the reference must be + in a formatted object that is reachable from a root, or + actually in a root (such as a scanned stack).
+ +It is okay for a careful client to hold unmanaged references, + but:
+mps_reserve returns a reference to a piece
+ of new memory for the client to build a new object in.
+ During this build, the MPS pins the piece of memory, and
+ treats it as raw data.
"Pinned" means: it will not move, be collected, be unmapped, + or anything like that.
+ +"Raw data" means two things:
+ +Firstly, "raw data" means that any references stored IN the + new object are unmanaged. This means:
+Secondly, "raw data" means that any references TO the new + object are treated like other references to unmanaged memory. + [.belief.refs-to-uninit-safe: + We're 'sure', but I need to check this. What does Fix + actually do with a pointer into the init-alloc zone? We + hope it ignores it. RHSK 2006-06-09] + Because of this, you are permitted to connect the new object + into your graph of managed objects immediately. The MPS gives + you these guarantees:
+mps_commit below!)The client will typically do all these things:
+However, during the build, the client MUST NOT read + (from the new object) a reference to an existing mobile object -- + because the reference is unmanaged and may be stale.
+ +(Actually, the restriction is: the moment a reference to an + existing mobile object is written into the new object, that + reference (in the new object) may become stale. And you'd better + not use (dereference) a stale reference. And you'd better not + write it into any existing object. Writing it back into another + part of the new object is okay. Just don't trust it to be a valid + reference.)
+ +When you call mps_commit, it will either fail or succeed.
Almost always, mps_commit succeeds.
+ If it succeeds, that means:
Occasionally but rarely, mps_commit fails.
+ This means that the new object no longer exists.
+ The memory may even be unmapped by the time
+ mps_commit returns.
When this happens the client should take care to clear up any + managed references to the (now vanished) new object.
+ +[But there's a hole here, before the client does this. + Are managed (aka scanned) references TO + it still safe? They were safe during building + (by .belief.refs-to-uninit-safe). But now the AP pointers have + gone away. Are they still safe? + Clearly, if they are only RankAMBIG, they are safe. + What if they are RankEXACT? + RHSK 2006-06-09]
+ +[Discussion with RB 2006-06-09: yes, that's a problem for exact + references. Must not make any exact refs to a new object. And + unmanaged refs are not sufficient, because they won't preserve the + new object during commit. So must make at least one ambiguous + ref to new object before calling commit. That's the truth + currently. There are various ways to solve this to allow + purely-exact mutators. For instance, + keep the old init..alloc address-space flagged as a zombie zone, + until some communication with mutator (perhaps another reserve + from same AP?) indicates that mutator has removed all those + pesky exact refs to the now-dead ex-new object. RHSK 2006-06-09]
+ +The client will also have to re-create the object. For this + reason the standard allocation point idiom is:
+ +
+ do {
+ if (mps_reserve != MPS_RES_OK) {
+ goto fail_nomemory;
+ }
+ /* initialize my new object */
+ /* make an ambiguous reference to new object */
+ } while (! mps_commit);
+ /* link new object into my object graph */
+2006-06-02 RHSK Created. 2006-06-02 RHSK Introduction to MPS Formats 2006-06-06 RHSK Formats: clarify explanation of methods, copy method is obsolete, mention format variants. + 2006-06-09 RHSK Allocation points: how it's supposed to be, from RB 2006-06-09. + 2006-06-09 RHSK Allocation points: must make at least one ambiguous ref and no exact refs to new object before calling commit.