diff --git a/mps/design/locus/index.html b/mps/design/locus/index.html index 9b2df67dbda..b1308cdaef3 100644 --- a/mps/design/locus/index.html +++ b/mps/design/locus/index.html @@ -6,7 +6,7 @@
-This document contains a guide to the MPS locus manager, followed by the historical initial design. References, History, Copyright and License are at the end.
+ +Readership: any MPS developer. Not confidential.
+ + +The MPS manages three main resources:
+The locus manager manages address-space at the arena level.
+ +[Tucker was right: mail.ptw.1998-11-02.14-25. RHSK 2007-04-24].
+ +When a pool wants some address-space, it expresses some preferences to the locus manager. The locus manager and the arena (working together) try to honour these preferences, and decide what address-space the pool gets.
+ +Preferences are expressed by the SegPref argument to SegAlloc().
+ +Note that, when they call SegAlloc(), pools are asking for address-space and writeable storage simultaneously, in a single call. There is currently no way for pools to 'reserve' address space without requesting storage.
+ + +Carefully chosen addresses are used by reference tracing systems (ie. automatic pools), to:
+Different clumps will become worth collecting at different times (the classic example, of course, is generations in a generational collector). For these partial collections to be efficient, it must be cheap to keep these clumps differentiable, cheap to condemn (Whiten) a particular clump, and cheap to find a good conservative approximation to all inward references to a clump (both initially to constuct the Grey set, and to make scanning the Grey set efficient).
+ +This is what the MPS zone mechanism is all about.
+ +The locus manager manages the mapping from clumps to zones.
+ +To specify a clump, pools use the "SegPrefGen" tag to SegPrefExpress. [The name is misleading: generations are only one sort of clump. RHSK 2007-04-24]
+ + +Address-space is not infinite.
+ +In some use-cases, the MPS is required to remain efficient when using very nearly all available address-space and storage. (For example, with the client-arena class, where the only address-space available is that of the storage available).
+ +Even with the VM arena class, typical storage sizes (in the year 2007) can make 32-bit address-space constrained: the problem may have Order(4GB) size, which leaves little 'spare' address-space.
+ +Address-space fragmentation incurs failure when there is no way to allocate a big block of address-space. The big block may be requested via the MPS (by the client), or by something else in the same process, such as a 3rd-party graphics library, image library, etc.
+ +Address-space fragmentation incurs cost when:
+Storage is not infinite: it is allocated in multiples of a fixed-size tract. Small lonely objects, each retaining a whole tract, cause storage fragmentation.
+ +Non-moving pools manage this fragmentation with placement strategies that use:
+These pool-level strategies always care about contiguity of object storage. They also often care about on the ordering of addresses, because pool code uses an address-ordered search when choosing where to place a new object. Both of these mean that the address matters.
+ +Pools can specify a preference for High and Low ends of address-space, which implies a search-order. Pools could also specify clumping, using either SegPrefGen or SegPrefZoneSet.
+ + +The locus manager is not given advance notice of how much address-space will be required with what preferences. Instead, the locus manager starts with an empty 'layout', and adapts it as more requests come in over time. It is attempting to 'discover' a suitable layout by successive refinement. This is ambitious.
+ + +
THE DESIGN FOR THE LOCUS MANAGER
design.mps.locus
@@ -466,6 +558,7 @@ that PoolDestroy won't have to be used for that purpose.
+| 2002-06-07 | -RB | -Converted from MMInfo database design document. | +
| 2007-04-24 | +RHSK | +add Guide: Manage arena address-space, why, discover layout. |
This document is copyright © 1995-2002 Ravenbrook Limited. All rights reserved. This is an open source license. Contact Ravenbrook for commercial licensing options.
+This document is copyright © 1995-2002, 2007 Ravenbrook Limited. All rights reserved. This is an open source license. Contact Ravenbrook for commercial licensing options.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: