1
Fork 0
mirror of git://git.sv.gnu.org/emacs.git synced 2026-03-26 08:41:47 -07:00

Minor edits.

Copied from Perforce
 Change: 180350
 ServerID: perforce.ravenbrook.com
This commit is contained in:
Gareth Rees 2012-11-05 22:29:36 +00:00
parent c3215d9102
commit 52236aae84
14 changed files with 142 additions and 73 deletions

View file

@ -14,7 +14,7 @@
id="svg2"
version="1.1"
inkscape:version="0.48.2 r9819"
sodipodi:docname="New document 1">
sodipodi:docname="symbol-table.svg">
<defs
id="defs4">
<marker
@ -54,8 +54,8 @@
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="1"
inkscape:cx="288.99598"
inkscape:cy="182.34538"
inkscape:cx="111.99598"
inkscape:cy="172.84538"
inkscape:document-units="px"
inkscape:current-layer="layer1"
showgrid="true"
@ -80,7 +80,7 @@
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title></dc:title>
<dc:title />
</cc:Work>
</rdf:RDF>
</metadata>
@ -94,23 +94,23 @@
id="rect2987"
width="90"
height="20"
x="80"
x="120"
y="672.36218" />
<text
xml:space="preserve"
style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="90"
x="130"
y="686.36218"
id="text3757"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan3759"
x="90"
x="130"
y="686.36218"
style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Verdana;-inkscape-font-specification:Verdana">TABLE</tspan></text>
<rect
y="692.36218"
x="80"
x="120"
height="20"
width="90"
id="rect3761"
@ -119,12 +119,12 @@
sodipodi:linespacing="125%"
id="text3763"
y="706.36218"
x="90"
x="130"
style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
xml:space="preserve"><tspan
style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Verdana;-inkscape-font-specification:Verdana"
y="706.36218"
x="90"
x="130"
id="tspan3765"
sodipodi:role="line">keys</tspan></text>
<rect
@ -132,18 +132,18 @@
id="rect3767"
width="90"
height="20"
x="80"
x="120"
y="712.36218" />
<text
xml:space="preserve"
style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="90"
x="130"
y="726.36218"
id="text3769"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan3771"
x="90"
x="130"
y="726.36218"
style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Verdana;-inkscape-font-specification:Verdana">values</tspan></text>
<rect
@ -222,13 +222,6 @@
x="280"
id="tspan3801"
sodipodi:role="line">name</tspan></text>
<rect
y="792.36218"
x="10"
height="20"
width="90"
id="rect3809"
style="fill:#f2f2f2;fill-opacity:1;stroke:#000000;stroke-width:0.99999994;stroke-linecap:butt;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" />
<rect
style="fill:#f2f2f2;fill-opacity:1;stroke:#000000;stroke-width:0.99999994;stroke-linecap:butt;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="rect3815"
@ -306,13 +299,6 @@
width="90"
id="rect3843"
style="fill:#f2f2f2;fill-opacity:1;stroke:#000000;stroke-width:0.99999994;stroke-linecap:butt;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" />
<rect
style="fill:#f2f2f2;fill-opacity:1;stroke:#000000;stroke-width:0.99999994;stroke-linecap:butt;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="rect3845"
width="90"
height="20"
x="390"
y="792.36218" />
<rect
y="812.36218"
x="390"
@ -392,18 +378,18 @@
y="1012.3622" />
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#DotM);marker-end:url(#Arrow1Mend)"
d="m 150,722.36218 240,70"
d="m 190,722.36218 200,70"
id="path3871"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#DotM);marker-end:url(#Arrow1Mend)"
d="m 150,702.36218 c 30,0 40,0 40,20 0,10 0.007,6.68771 0,30 0,20 -10,20 -40,20 -28.52438,0 -57.43061,0.005 -100,0 -30,0 -40,0 -40,20"
d="m 190,702.36218 c 30,0 40,0 40,20 0,10 0.007,6.68771 0,30 0,20 -10,20 -40,20 -28.52438,0 -97.43061,0.005 -140,0 -30,0 -40,0 -40,20"
id="path3875"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cccscc" />
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#DotM);marker-end:url(#Arrow1Mend)"
style="fill:none;stroke:#000000;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#DotM);marker-end:url(#Arrow1Mend);stroke-miterlimit:4;stroke-dasharray:2,1;stroke-dashoffset:0"
d="m 460,982.36218 c 30,0 40,0 40,-30 l 0,-150 c 0,-20 -10,-30 -30,-30 -40,0 -70.83211,0 -170,0 -19.06193,0 -30,10 -30,30 0,17.94046 0,49.89376 0,90"
id="path3879"
inkscape:connector-curvature="0"
@ -444,5 +430,74 @@
x="400"
id="tspan4705"
sodipodi:role="line">values</tspan></text>
<rect
y="792.36218"
x="10"
height="20"
width="90"
id="rect3928"
style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:0.99999994;stroke-linecap:butt;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" />
<text
sodipodi:linespacing="125%"
id="text3930"
y="806.36218"
x="16"
style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
xml:space="preserve"><tspan
style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Verdana;-inkscape-font-specification:Verdana"
y="806.36218"
x="16"
id="tspan3932"
sodipodi:role="line">dependent</tspan></text>
<rect
style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:0.99999994;stroke-linecap:butt;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="rect3940"
width="90"
height="20"
x="390"
y="792.36218" />
<text
xml:space="preserve"
style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="396"
y="806.36218"
id="text3942"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan3944"
x="396"
y="806.36218"
style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Verdana;-inkscape-font-specification:Verdana">dependent</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#DotM);marker-end:url(#Arrow1Mend)"
d="M 90,140 390,130"
id="path3946"
inkscape:connector-curvature="0"
transform="translate(0,662.36218)" />
<path
style="fill:none;stroke:#000000;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#DotM);marker-end:url(#Arrow1Mend);stroke-miterlimit:4;stroke-dasharray:2,1;stroke-dashoffset:0"
d="m 470,140 c 0,-40 0,-50 -20,-50 L 30,90 c -20,0 -20,10 -20,40"
id="path4316"
inkscape:connector-curvature="0"
transform="translate(0,662.36218)"
sodipodi:nodetypes="cccc" />
<text
xml:space="preserve"
style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Verdana;-inkscape-font-specification:Verdana Bold"
x="12"
y="676.36218"
id="text4686"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4688"
x="12"
y="676.36218"
style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr;text-anchor:start;font-family:Verdana;-inkscape-font-specification:Verdana Bold">symtab</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#DotM);marker-end:url(#Arrow1Mend)"
d="m 70,10 50,0"
id="path4690"
inkscape:connector-curvature="0"
transform="translate(0,662.36218)" />
</g>
</svg>

Before

Width:  |  Height:  |  Size: 19 KiB

After

Width:  |  Height:  |  Size: 22 KiB

Before After
Before After

View file

@ -582,7 +582,11 @@ A one-bit tag suffices here::
obj_t bucket[1]; /* hash buckets */
} buckets_s, *buckets_t;
Now the full details of the scan method can be given::
Now the full details of the scan method can be given, with the revised
code highlighted:
.. code-block:: c
:emphasize-lines: 6-9, 16-22
static mps_res_t buckets_scan(mps_ss_t ss, mps_addr_t base, mps_addr_t limit)
{
@ -730,9 +734,9 @@ as a string object, instead of containing the name itself.
.. figure:: ../diagrams/symbol-table.svg
:align: center
:alt: Diagram: Global symbol table design.
:alt: Diagram: Global symbol table design (weak references shown as dashed lines).
Global symbol table design.
Global symbol table design (weak references shown as dashed lines).
This design depends on the string object containing the symbol name
being immutable. As it happens, all strings are immutable, because the

View file

@ -112,7 +112,9 @@ AMC interface
mps_chain_t chain)
``fmt`` specifies the :term:`object format` for the objects
allocated in the pool.
allocated in the pool. The format must provide a :term:`scan
method`, a :term:`skip method`, a :term:`forward method`, an
:term:`is-forwarded method` and a :term:`padding method`.
``chain`` specifies the :term:`generation chain` for the pool.

View file

@ -65,6 +65,8 @@ AMCZ interface
mps_chain_t chain)
``fmt`` specifies the :term:`object format` for the objects
allocated in the pool.
allocated in the pool. The format must provide a :term:`skip
method`, a :term:`forward method`, an :term:`is-forwarded method`
and a :term:`padding method`.
``chain`` specifies the :term:`generation chain` for the pool.

View file

@ -112,7 +112,8 @@ AMS interface
mps_chain_t chain)
``fmt`` specifies the :term:`object format` for the objects
allocated in the pool.
allocated in the pool. The format must provide a :term:`scan
method` and a :term:`skip method`.
``chain`` specifies the :term:`generation chain` for the pool. It
must have a single generation.

View file

@ -324,7 +324,8 @@ AWL interface
mps_awl_find_dependent_t find_dependent)
``fmt`` specifies the :term:`object format` for the objects
allocated in the pool.
allocated in the pool. The format must provide a :term:`scan
method` and a :term:`skip method`.
``find_dependent`` is a function of type
:c:type:`mps_awl_find_dependent_t` that specifies how to find the

View file

@ -9,8 +9,8 @@
.. _pool-lo:
LO (Leaf Only)
==============
LO (Leaf Object)
================
**LO** is an :term:`automatically managed <automatic memory
management>` :term:`pool class` for :term:`leaf objects` (objects that
@ -101,7 +101,8 @@ LO interface
.. c:function:: mps_class_t mps_class_lo(void)
Return the :term:`pool class` for an LO (Leaf Only) :term:`pool`.
Return the :term:`pool class` for an LO (Leaf Object)
:term:`pool`.
When creating an LO pool, :c:func:`mps_pool_create` takes one
extra argument::
@ -111,4 +112,5 @@ LO interface
mps_fmt_t fmt)
``fmt`` specifies the :term:`object format` for the objects
allocated in the pool.
allocated in the pool. The format must provide a :term:`skip
method`.

View file

@ -108,7 +108,7 @@ MV interface
``debug_option`` specifies the debugging options. See
:c:type:`mps_debug_option_s`.
``extend_szie``, ``average_size`` and ``maximum_size`` are as
``extend_size``, ``average_size`` and ``maximum_size`` are as
documented in :c:func:`mps_class_mv`.

View file

@ -30,10 +30,10 @@ on the same pool, because the worst-fit policy of buffer filling will
grab all the large blocks, leading to severe fragmentation. If you
need both forms of allocation, use two separate pools.
Note that using buffered allocation prevents (for obscure technical
reasons) the pool from allocating across segment boundaries. This can
cause added external fragmentation if objects are allocated that are a
significant fraction of the segment size.
Note that buffered allocation can't allocate across segment boundaries
(see :ref:`topic-allocation-point-implementation` for the technical
reason). This can cause added external fragmentation if objects are
allocated that are a significant fraction of the segment size.
.. note::
@ -167,7 +167,7 @@ MVFF introspection
#include "mpscmvff.h"
.. c:function:: size_t mps_mvff_free_size(mps_pool_t mpspool)
.. c:function:: size_t mps_mvff_free_size(mps_pool_t pool)
Return the total amount of free space in an MVFF pool.

View file

@ -12,8 +12,8 @@ MVT (Manual Variable Temporal)
==============================
**MVT** :term:`manually manages <manual memory management>`
variable-sized, unformatted objects. It uses an :term:`allocation
policy` termed :dfn:`temporal fit`.
variable-sized, unformatted objects. It uses the :dfn:`temporal fit`
:term:`allocation policy`.
.. index::
@ -24,14 +24,14 @@ Temporal fit
------------
Temporal fit attempts to place consecutive allocations next to each
other. It relies on delaying reuse as long as possible to permit freed
other. It relies on delaying re-use as long as possible to permit freed
blocks to :term:`coalesce`, thus maximizing the number of consecutive
allocations that can be co-located. Temporal fit permits a very fast
allocator and a deallocator competitive in speed with all other known
policies.
Temporal fit is intended to take advantage of knowledge of object
:term:`lifetimes`, either *a priori* knowledge, or knowledge acquired
:term:`lifetimes`: either *a priori* knowledge, or knowledge acquired
by profiling. The best performance will be achieved by allocating
objects with similar expected death times together.
@ -45,10 +45,10 @@ An application that has several classes of objects of widely differing
life expectancy will best be served by creating a different MVT pool
instance for each life-expectancy class. A more sophisticated policy
can use either the programmer's knowledge of the expected lifetime of
an objector any characteristic of objects that correlates with
lifetime to choose an appropriate pool instance to allocate in.
an object, or any characteristic of objects that correlates with
lifetime, to choose an appropriate pool to allocate in.
Allocating objects with unknown or very different deathtimes together
Allocating objects with unknown or very different death times together
will pessimize the space performance of MVT.
@ -158,8 +158,8 @@ MVT interface
object population does vary, at a slight cost in efficiency. The
reserve does not guarantee any particular amount of allocation.
``fragmentation_limit`` is a percentage in (0, 100] that can be used
to set an upper limit on the space overhead of MVT in case block
``fragmentation_limit`` is a percentage from 1 to 100 (inclusive).
It sets an upper limit on the space overhead of MVT, in case block
death times and allocations do not correlate well. If the free
space managed by the pool as a ratio of all the space managed by
the pool exceeds ``fragmentation_limit``, the pool falls back to a
@ -168,14 +168,14 @@ MVT interface
the pool to operate as a first-fit pool, at a significant cost in
time efficiency: therefore this is not permitted.
A fragmentation limit of 100 will cause the pool to use temporal
fit (unless resources are exhausted). If the objects allocated in
the pool have similar lifetime expectancies, this mode will have
the best time- and space-efficiency. If the objects have widely
varying lifetime expectancies, this mode will be time-efficient,
but may be space-inefficient. An intermediate setting can be used
to limit the space-inefficiency of temporal fit due to varying
object life expectancies.
A fragmentation limit of 100 causes the pool to always use
temporal fit (unless resources are exhausted). If the objects
allocated in the pool have similar lifetime expectancies, this
mode will have the best time- and space-efficiency. If the objects
have widely varying lifetime expectancies, this mode will be
time-efficient, but may be space-inefficient. An intermediate
setting can be used to limit the space-inefficiency of temporal
fit due to varying object life expectancies.
.. index::

View file

@ -103,8 +103,8 @@ SNC introspection
mps_fmt_t fmt)
``fmt`` specifies the :term:`object format` for the objects
allocated in the pool. The format should provide at least the
methods scan, skip, and pad.
allocated in the pool. The format must provide a :term:`scan
method`, a :term:`skip method`, and a :term:`padding method`.
When creating an allocation point on an SNC pool,
:c:func:`mps_ap_create` takes one extra argument::

View file

@ -506,6 +506,8 @@ A correct version of ``insert_link`` looks like this::
.. index::
single: allocation points; implementation
.. _topic-allocation-point-implementation:
Allocation point implementation
-------------------------------

View file

@ -295,7 +295,7 @@ default.
The cool variety is intended for development and testing.
All functions check the consistency of their data structures and
may assert, including function on the :term:`critical path`.
may assert, including functions on the :term:`critical path`.
All events are sent to the :term:`telemetry stream`, including
events on the :term:`critical path`.

View file

@ -18,15 +18,15 @@
Plinth
======
The :dfn:`plinth` is a program module providing the MPS with all the
support it needs from the execution environment. It serves two
purposes, both relating to operating system support:
The :dfn:`plinth` is a program module that provides the MPS with the
support it needs from the execution environment. The MPS uses the plinth instead of (say) the Standard C Library because:
1. The MPS is designed to be portable to systems that have only a
*conforming freestanding implementation* of the C language: that
is, systems which potentially lack facilities of the Standard C
Library, such as Standard I/O. The plinth provides all the
necessary facilities.
is, systems which potentially lack some of the facilities of the
Standard C Library, such as standard I/O. The plinth provides a way
to map MPS requirements to the facilities provided on the platform,
whatever they are.
2. The plinth gives the :term:`client program` complete control of
interaction between the MPS and the user, including