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:
parent
64b873a2bc
commit
18f85f59aa
3 changed files with 25 additions and 12 deletions
|
|
@ -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``.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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`.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue