1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
.. _glossary-h:

=============================
Memory Management Glossary: H
=============================

.. include:: alphabet.txt

.. glossary::

    handle

        A handle is an object that represents a resource.

        Handles are used when the resource cannot be represented
        directly. For example, a file handle is an object passed
        between a process and the OS in order to access a file,
        because the file itself cannot be represented.

        .. relevance::

            In memory management, a handle is an object that
            represents another :term:`object`. Handles are usually
            used because the object itself needs to be :term:`moved
            <moving garbage collector>` in :term:`memory (2)`, or even
            :term:`swapped out` to disk. The program therefore cannot
            know the :term:`address` of the object.

        For example, Apple's Classic Mac OS made extensive use of
        handles in its `heap management
        <http://web.archive.org/web/200012120034/http://developer.apple.com/techpubs/mac/Memory/Memory-11.html>`_
        to avoid problems due to :term:`fragmentation`. If the Classic
        Mac OS Memory Manager could not satisfy a request for memory,
        it tried :term:`compacting <compaction>` the :term:`heap`:
        moving all the :term:`relocatable <relocation>` objects
        together to squeeze out gaps. It could do this because the
        program only had handles on the objects, and not their actual
        addresses.

        .. figure:: ../diagrams/handle.svg
            :align: center
            :alt: Diagram: Handle-based heap.

            Handle-based heap.

        .. similar:: :term:`pointer`.

    header

        .. see:: :term:`in-band header`.

    heap

        .. aka:: *free store*, *freestore*.

        The *heap* or *free store* is the :term:`memory (2)` area
        managed by :term:`dynamic allocation`.

        This use of *heap* is unconnected with the data structure used
        by the heapsort algorithm.

    heap allocation

        .. aka:: *dynamic allocation*.

        *Heap allocation* or *dynamic allocation* means run-time
        :term:`allocation <allocate>` and :term:`deallocation <free
        (1)>` of :term:`memory (1)` in arbitrary order.

        Dynamic allocation is usually for :term:`objects`
        whose size, quantity, or :term:`lifetime` could not be
        determined at compile-time. It is necessary to implement
        modern data structures, such as recursive trees and full
        :term:`closures`.

        Objects on the :term:`heap` can be managed :term:`manually
        <manual memory management>`, as in :term:`C`, or
        :term:`automatically <automatic memory management>`, as in
        :term:`Lisp` and :term:`Java`.

        .. opposite:: :term:`stack allocation`, :term:`static allocation`.

        .. seealso:: :term:`indefinite extent`.

    hit

        A hit is a successful lookup in any form of :term:`cache (3)
        <caching (3)>`, most commonly at some level of a
        :term:`storage hierarchy`, such as a :term:`cache (1)` or
        :term:`virtual memory` system.

        .. opposite:: :term:`miss`.

    hit rate

        At any level of a :term:`storage hierarchy`, the hit rate is
        the proportion of accesses which :term:`hit`.

        .. opposite:: :term:`miss rate`.

    hot

        .. mps:specific::

            A :term:`variety` in which many MPS functions
            :term:`assert <assertion>` that their data structures are
            valid, but functions on the :term:`critical path` do not.
            Select it by defining :c:macro:`CONFIG_VAR_HOT`. Compare
            :term:`cool` and :term:`rash`.

    huge page

        .. aka:: *large page*, *superpage*.

        Some processor architectures support multiple :term:`page`
        sizes. This allows operating systems to better match the page
        size to the granularity of memory usage and so reduce the size
        of the :term:`page table`.