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

Actions from meeting with rb.

Copied from Perforce
 Change: 180277
 ServerID: perforce.ravenbrook.com
This commit is contained in:
Gareth Rees 2012-11-02 14:15:36 +00:00
parent 64b873a2bc
commit 18f85f59aa
3 changed files with 25 additions and 12 deletions

View file

@ -342,4 +342,5 @@ AWL interface
null pointer if there is none.
The dependent object need not be in memory managed by the MPS, but
if it is, then it must be in a pool in the same arena as ``addr``.
if it is, then it must be in a :term:`non-moving <non-moving
garbage collection>` pool in the same arena as ``addr``.

View file

@ -52,13 +52,6 @@ Outstanding
126. Things that are "within reach", i.e. that we could do if people
needed them. (RB needs to write this.)
144. In AWL, what are the restrictions on the dependent object? Must
it be another object in AWL? What are we allowed to do with it?
What state will the object be in when we look at it? Does it have
to be fixed?
145. Can you use the same generation chain with more than one pool?
Complete
--------
@ -1120,3 +1113,20 @@ Complete
us."
*Action:* see :ref:`pool-awl`.
144. In AWL, what are the restrictions on the dependent object? Must
it be another object in AWL? What are we allowed to do with it?
What state will the object be in when we look at it? Does it have
to be fixed?
*Answer:* better not be in a moving pool (otherwise might point
to forwarding object). You can fix it, but the fixed-up reference
won't necessarily be exposed. Let's document, "dependent object
must be in a non-moving pool, or in memory not managed by the
MPS." (Should fix the dependent object; that may result in the
reference being splatted if the dependent object died.)
145. Can you use the same generation chain with more than one pool?
*Answer:* not only can you do this, but you ought to.

View file

@ -21,10 +21,12 @@ Garbage collection
Generation chains
-----------------
Each :term:`automatically managed <automatic memory management>`
:term:`pool` has an associated :term:`generation chain` which
describes the structure of the :term:`generations` in
that pool. You create a generation chain by preparing an array of
A :term:`generation chain` describes the structure of the
:term:`generations` in a set of :term:`automatically managed
<automatic memory management>` :term:`pools`. The same generation
chain should be used for all pools whose blocks live and die together.
Create a generation chain by preparing an array of
:c:type:`mps_gen_param_s` structures giving the *capacity* (in
kilobytes) and *predicted mortality* (between 0 and 1) of each
generation, and passing them to :c:func:`mps_chain_create`.