.. mode: -*- rst -*-

Fail-over allocator
===================

:Tag: design.mps.failover
:Author: Gareth Rees
:Date: 2014-04-01
:Status: complete design
:Revision: $Id$
:Copyright: See section `Copyright and License`_.
:Index terms: pair: fail-over allocator; design


Introduction
------------

_`.intro`: This is the design of the fail-over allocator, a data
structure for the management of address ranges.

_`.readership`: This document is intended for any MPS developer.

_`.source`: design.mps.land_, design.mps.poolmvt_, design.mps.poolmvff_.

_`.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
---------

_`.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_.


Types
.....

``typedef struct FailoverStruct *Failover``

_`.type.failover`: The type of fail-over allocator structures. A
``FailoverStruct`` is typically embedded in another structure.


Classes
.......

_`.class`: ``CLASS(Failover)`` is the fail-over allocator class, a
subclass of ``CLASS(Land)`` suitable for passing to ``LandInit()``.


Keyword arguments
.................

When initializing a fail-over allocator, ``LandInit()`` requires these
two keyword arguments:

* ``FailoverPrimary`` (type ``Land``) is the primary land.

* ``FailoverSecondary`` (type ``Land``) is the secondary land.


Implementation
--------------

_`.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:

_`.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.

_`.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).



Document History
----------------

- 2014-04-03 GDR_ Created.

.. _GDR: https://www.ravenbrook.com/consultants/gdr/


Copyright and License
---------------------

Copyright © 2014–2020 `Ravenbrook Limited <https://www.ravenbrook.com/>`_.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:

1. Redistributions of source code must retain the above copyright
   notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.

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 AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
HOLDER OR 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.
