Fail-over allocator =================== .. mps:prefix:: design.mps.failover Introduction ------------ :mps:tag:`intro` This is the design of the fail-over allocator, a data structure for the management of address ranges. :mps:tag:`readership` This document is intended for any MPS developer. :mps:tag:`source` design.mps.land_, design.mps.poolmvt_, design.mps.poolmvff_. :mps:tag:`overview` The fail-over allocator combines two *land* instances. It stores address ranges in one of the lands (the *primary*) unless insertion fails, in which case it falls back to the other (the *secondary*). The purpose is to be able to combine two lands with different properties: with a CBS_ for the primary and a Freelist_ for the secondary, operations are fast so long as there is memory to allocate new nodes in the CBS, but operations can continue using the Freelist when memory is low. .. _CBS: cbs .. _Freelist: freelist .. _design.mps.land: land .. _design.mps.poolmvt: poolmvt .. _design.mps.poolmvff: poolmvff Interface --------- :mps:tag:`land` The fail-over allocator is an implementation of the *land* abstract data type, so the interface consists of the generic functions for lands. See design.mps.land_. External types .............. .. c:type:: struct FailoverStruct *Failover :mps:tag:`type.failover` The type of fail-over allocator structures. A :c:type:`FailoverStruct` may be embedded in another structure, or you can create it using :c:func:`LandCreate()`. External functions .................. .. c:function:: LandClass FailoverLandClassGet(void) :mps:tag:`function.class` The function :c:func:`FailoverLandClassGet()` returns the fail-over allocator class, a subclass of :c:type:`LandClass` suitable for passing to :c:func:`LandCreate()` or :c:func:`LandInit()`. Keyword arguments ................. When initializing a fail-over allocator, :c:func:`LandCreate()` and :c:func:`LandInit()` require these two keyword arguments: * ``FailoverPrimary`` (type :c:type:`Land`) is the primary land. * ``FailoverSecondary`` (type :c:type:`Land`) is the secondary land. Implementation -------------- :mps:tag:`impl.assume` The implementation assumes that the primary is fast but space-hungry (a CBS) and the secondary is slow but space-frugal (a Freelist). This assumption is used in the following places: :mps:tag:`impl.assume.flush` The fail-over allocator attempts to flush the secondary to the primary before any operation, in order to benefit from the speed of the primary wherever possible. In the normal case where the secondary is empty this is cheap. :mps:tag:`impl.assume.delete` When deletion of a range on the primary fails due to lack of memory, we assume that this can only happen when there are splinters on both sides of the deleted range, one of which needs to be allocated a new node (this is the case for CBS), and that therefore the following procedure will be effective: first, delete the enclosing range from the primary (leaving no splinters and thus requiring no allocation), and re-insert the splinters (failing over to the secondary if necessary).