This wiki article contains incomplete and informal notes about the MPS, the precursor to more formal documentation. Not confidential. Readership: MPS users and developers.
This is a temporary collection of addenda (additions and corrections) that should go into the reference manual (RefMan). It is much better to put corrections straight into the reference manual (if possible), instead of here.
...But sometimes you need to collect information, of which some should go to RefMan and some should go into design docs etc. You can collect that sort of information here.
...And sometimes it really doesn't seem that all this information should be part of the declared public interface.
mps_class_amc, mps_class_amsCreate a chain with mps_chain_create, and pass it as argument to mps_pool_create for these two pool classes.
Pool class AMS is non-generational, and must have a chain with one element ('generation') specifying a capacity and predicted mortality. This capacity is not a limit: it is only used to prompt collection of the AMS objects.
Pool class AMC is generational: the chain specifies capacity and predicted mortality of each generation. These capacities are not limits: they are used for scheduling collection of the AMC objects.
The way chains affect garbage collection is discussed in the GC Story article.
mps_arena_step, mps_arena_start_collectWhen the client has some idle-time, it is permitted to call mps_arena_step(arena, interval, multiplier) to allow MPS to do collection work. The "interval" argument (units: seconds) specifies how much time the MPS is permitted to take with this mps_arena_step call. The "multiplier" argument specifies how many further similar calls to mps_arena_step the Client expects to make in this period of idle time. The idea is that the MPS should return before "interval" is exhausted, and should only eagerly commence long-duration operations that consume CPU (such as a full collection) if those operations are expected to be completed within "multiplier * interval" seconds.
Note that mps_arena_step will still step, even if the arena has been clamped. This is to allow a client to advance a collection only at these mps_arena_step points (but note that barrier hits will also cause collection work).
The client is permitted to request a full collection with mps_arena_start_collect. The MPS returns 'asynchronously' from this call, usually before full collection has completed. (Contrast the mps_arena_collect call, which does not return until the full collection has completed). Work on the full collection then proceeds incrementally, just as it does when the MPS schedules a full collection automatically.
Fuller documentation is currently only in email. See:
2006-11-28 RHSK Created: chain for AMC and AMS; mps_arena_step
and mps_arena_start_collect.
2006-12-29 RHSK More comments on chain and arena_start/_step.
This document is copyright © 2006 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:
This software is provided by the copyright holders and contributors "as is" and any express or implied warranties, including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement, are disclaimed. In no event shall the copyright holders and contributors be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, procurement of substitute goods or services; loss of use, data, or profits; or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of this software, even if advised of the possibility of such damage.