.. _glossary-w: ============================= Memory Management Glossary: W ============================= .. include:: alphabet.txt .. glossary:: weak-key hash table A hash table which has :term:`weak references (1)` to its keys. If the key dies, the value for that key is automatically deleted from the table too. It can be used to store extra information about objects without keeping them alive. .. similar:: :term:`doubly weak hash table`, :term:`weak-value hash table`. .. mps:specific:: See :ref:`pool-awl`. weak-value hash table A hash table which has :term:`weak references (1)` to its value. If the value dies, any keys that refer to that value are automatically deleted from the table too. It can be used to index a set of objects without keeping them alive. .. similar:: :term:`doubly weak hash table`, :term:`weak-key hash table`. .. mps:specific:: See :ref:`pool-awl`. weak hash table A :term:`weak-key ` or :term:`weak-value hash table` (usually the former). weak reference (1) In :term:`tracing garbage collection`, a weak reference is a :term:`reference` that does not keep the :term:`object` it refers to :term:`alive `. A weak reference does not keep the referent alive, but it will continue to refer to the object as long as it remains otherwise alive. When only weak references to the object remain, the weak references can be deleted ("splatted" or "cleared") and the object :term:`reclaimed`. :term:`Java` offers three kinds of weak references, called :term:`soft references`, :term:`weak references (2)`, and :term:`phantom references`, in order of increasing weakness. .. opposite:: :term:`strong reference`. .. seealso:: :term:`weak root`. weak reference (2) In :term:`Java` terminology, *weak reference* is used to mean a :term:`reference` encapsulated in a :term:`reference object` of class ``WeakReference``. Weak references form one of three kinds of :term:`weak reference (1)` in Java. They are handy for associating extra data with objects when you cannot store it in the objects themselves. .. seealso:: :term:`weakly reachable`. .. link:: `Class java.lang.ref.WeakReference `_, `Reference Objects and Garbage Collection `_. weak root A weak root is a :term:`root`, such that all :term:`references` in it are :term:`weak references (1)`; that is, they do not affect the :term:`liveness ` of the :term:`objects` referred to. .. opposite:: :term:`strong root`. .. mps:specific:: A weak root has :term:`rank` :c:func:`mps_rank_weak`. weak tri-color invariant weak tri-colour invariant weak tricolor invariant weak tricolour invariant The weak :term:`tri-color invariant` is the property of a :term:`reference` :term:`graph` that all :term:`white` :term:`nodes` pointed to by a :term:`black` node are also :term:`reachable` from some :term:`gray` node through a chain of white nodes. By preserving this property throughout :term:`tri-color marking`, a :term:`tracing ` algorithm can ensure that the :term:`collector (2)` will not miss reachable objects, even if the :term:`mutator` manipulates the graph during the collection. Mutator actions might need to change the :term:`color` of the nodes affected in order to preserve the invariant. Algorithms using this invariant are :term:`snapshot-at-the-beginning ` algorithms. .. seealso:: :term:`barrier (1)`, :term:`strong tri-color invariant`. .. bibref:: :ref:`Johnstone (1997) `, :ref:`Pirinen (1998) `. weakly reachable In :term:`Java`, an object is *weakly reachable* if it is neither :term:`strongly ` nor :term:`softly reachable` and there is a path from the :term:`roots` to it that contains at least one :term:`weak reference (2)` but no :term:`phantom references`. When the Java :term:`collector (1)` determines that an object is weakly reachable, it clears all the weak references involved, and declares the object :term:`finalizable `. (Operationally, finalization works as if it was implemented by a class of "final references" that stand between weak and phantom references.) Also, the :term:`reference objects` containing the weak references are enqueued, if they were registered with a queue. .. seealso:: :term:`reachability `, :term:`phantom reachable`. .. link:: `Class java.lang.ref.WeakReference `_, `Reference Objects and Garbage Collection `_. weighted buddies A :term:`buddy system` :term:`allocation mechanism` using two series of size classes: :term:`binary buddies` (2, 4, 8, …) and three-times-power-of-two (3, 6, 12, …). A block that is in the latter series may be :term:`split` in two different ways. Thus a block of size 12 may be split into two blocks of size 6 or one block of size 4 and one block of size 8. The same applies for :term:`coalescing `. This gives this system more flexibility than a regular buddy system. .. seealso:: :term:`buddy system`, :term:`allocation mechanism`, :term:`binary buddies`. .. bibref:: :ref:`Wilson et al. (1995) `. weighted reference counting A technique for :term:`reference counting` which is in common use for :term:`distributed garbage collection` because of the low level of inter-process communication it requires. Inter-process :term:`references` to :term:`objects` are counted, but instead of simply counting the number of references, each reference is given a weight. When an object is created, the initial pointer to it is assigned a weight, which is usually a power of 2 for easy division. The object records the sum of all the weights of all of its references. Whenever a reference is copied, its weight is divided equally between the new and original copies. Since this operation preserves the weighted reference sum, there is no need for communication with the object at this time. When a reference is deleted, the weighted reference sum is decremented by the weight of the reference. This is communicated to the object by sending it a message. When the object detects that the weighted reference sum has dropped to zero, it may be :term:`reclaimed`. The algorithm is tolerant of communication protocols which don't guarantee order of arrival of deletion messages. white In a :term:`tri-color marking` scheme, white :term:`objects` are objects that were :term:`condemned ` at the beginning of the :term:`collection cycle` and have not been shown to be :term:`reachable`. When :term:`tracing ` is complete, white objects will be subject to :term:`reclamation `. .. opposite:: :term:`gray`, :term:`black`. word .. aka:: *machine word*. Almost all processor architectures have a characteristic data size that is handled most efficiently. This is known as the *word size*, and data of that size are known as *words*. The word size is usually a power of two multiple of :term:`bytes (2)`. Often the platform's word size is used to characterize the architecture by quoting the number of bits in it. For example, a 32-bit platform has a word size of four bytes and a 64-bit platform has eight-byte words (assuming 8-bit bytes). Typically, :term:`pointers` are the size of a word, and traditionally this determined the word size. Nowadays, word size is usually driven by the need for more accuracy and range in mathematical calculations. .. historical:: In the past, the convenience of dealing with powers of two was not as significant, and word sizes such as 36- or 72-bits were not unknown. .. seealso:: :term:`alignment`, :term:`grain`. working set The working set of a program or system is that :term:`memory (2)` or set of :term:`addresses` which it will use in the near future. This term is generally used when discussing :term:`miss rates` at some :term:`storage level`; the time scale of "near future" depends upon the cost of a :term:`miss`. The working set should fit in the storage level; otherwise the system may :term:`thrash`. .. seealso:: :term:`resident set`, :term:`cache (2)`, :term:`storage hierarchy`. .. bibref:: :ref:`Denning & Schwartz (1972) `. worst fit The :term:`allocation policy` that always allocates from the largest :term:`free block`. Commonly implemented using a size-ordered :term:`free block chain` (largest first). In practice, this tends to work quite badly because it eliminates all large blocks, so large requests cannot be met. .. seealso:: :term:`allocation policy`, :term:`first fit`, :term:`best fit`. .. bibref:: :ref:`Wilson et al. (1995) `. wrapped A value is wrapped if it is encoded with type information. .. opposite:: :term:`unwrapped`. .. seealso:: :term:`wrapper`, :term:`boxed`, :term:`tag`. .. bibref:: :ref:`Gudeman (1993) `. wrapper A wrapper is that part of a :term:`wrapped` representation that is copied when the value is passed by value. The wrapper does not include parts of the representation that are accessed indirectly, and are not copied when the value is passed. For instance, a :term:`Lisp` implementation might use the top two bits of a value representation as a :term:`tag` to distinguish between integers and :term:`cons (1)` cells, setting these bits to 01 for a :term:`pointer` to a cons cell and 11 for an integer. Then the wrapped value of the number 4 would have binary representation 11000…00100, and the wrapper for this number is the whole of this wrapped value. The pointer to a cons cell stored at location 4 would have binary representation 01000…00100. The wrapped value of the cons cell is the combination of this pointer and the cons cell in memory itself. The wrapper of the cons cell is just the pointer; when the cons cell is passed as a function argument, just the pointer is passed. .. seealso:: :term:`wrapped`, :term:`boxed`. .. bibref:: :ref:`Gudeman (1993) `. write barrier A write :term:`barrier (1)` is a block on writing to certain :term:`memory (2)` :term:`locations ` by certain threads or processes. .. relevance:: Write barriers are used for :term:`incremental ` or :term:`concurrent ` :term:`garbage collection`. They are also used to maintain :term:`remembered sets` for :term:`generational ` :term:`collectors (1) `. .. seealso:: :term:`read barrier`. write fault An exception which occurs when writing to an address in :term:`virtual memory`. This is probably either a :term:`page fault`, an :term:`invalid page fault` or a :term:`protection fault`. .. similar:: :term:`segmentation violation`. .. seealso:: :term:`read fault`.