Ravenbrook / Projects / Memory Pool System / Issues

Memory Pool System


MPS issue job001658

Title: Finalization messages are unnecessarily delayed.
Status: closed
Priority: essential
Assigned user: David Jones
Product: mps
Organization: Ravenbrook
Description: Finalization messages are unnecessarily delayed.

See also drj's e-mail [1].

As soon as the minimum rank of a grey segment is RankFINAL the MPS
could scan _all_ RankFINAL segments and thereby post finalization
messages for all currently f-reachable objects.

This could be a reason why Configura's objects are not finalized early
enough. See job001639 for a more Configura-specific view.
Analysis: Currently the MPS does not do this. It will revert to scanning
RankEXACT segments containing the objects registered for finalization.
If these objects refer to other objects registered for finalization
then finalization messages for those objects will not be enqueued even
when it would be legal to do so. In the worst case only 1 f-reachable
object per collection will have a finalization message enqueued.

More analysis and suggested solution in [1].

RHSK 2007-06-21

See branch/2007-04-18/diag/...@162630. Run new test fint1658 in
variety.di (diagnostic output).
Shows that, after finding one RankFINAL segment, traceFindGrey then
goes back to RankEXACT segs before tracing the next RankFINAL segment.
(Does not yet show that this causes less-than-prompt finalization).

Now try @162631, with test fin1658a.
Shows that, if a pair of finalizable objects refer to each other,
that can prevent them both being finalized in the same cycle.

RHSK 2007-06-22

branch/2007-04-18/diag/...@162647. Run w3build.bat.
Use di contents to replace we, and cvm make new.
See [2] for results. It confirms that MPS reverts to scanning at
exact, which is strongly expected to make finalization unnecessarily
less prompt (as verified the fin1658a test).
How found: unknown
Evidence: [1] http://info.ravenbrook.com/mail/2007/06/04/10-32-20/0.txt
[2] http://info.ravenbrook.com/project/mps/branch/2007-04-18/diag/code/exp-162647/0622a-tFGreport.txt
Observed in: 1.107.0
Introduced in: 0.0.0
Test procedure: none
Created by: David Jones
Created on: 2007-06-04 12:09:40
Last modified by: Richard Kistruck
Last modified on: 2007-07-06 14:56:36
History: 2007-06-04 DRJ Created.
2007-06-21 RHSK fint1658 shows traceFindGrey behaviour
2007-06-21 RHSK fin1658a shows defect
2007-06-22 RHSK traceFindGrey behaviour shown in CM

Fixes

Change Effect Date User Description
162787 closed 2007-07-05 18:13:01 Richard Kistruck MPS master: integ from br/band/...@162786:

trace.c, design/trace, mpmst.h:
- fix job001658;
- (by making traceFindGrey aware of reference rank bands);
- tidy according to cstyle.

fin1658a.c, comm.gmk, commpost.nmk:
- new test for job001658.

tool/test-runner.py:
- platform detection.

w3build.bat:
- rearrange to reduce interleaving of different deliverables;
- only we, hi, di, ci;
- rmdir the release directory, before creating and populating it.
(version.c - empty-integrate)
162742 closed 2007-07-03 15:44:24 David Jones MPS: More checking.
162718 closed 2007-07-02 16:10:48 David Jones MPS: Implements better band tracing.
162696 open 2007-06-29 17:17:00 Richard Kistruck MPS br/diag: trace: New field in TraceStruct: TraceBand band for
current band (eg via-F) of trace. Fix for job001658.
162631 open 2007-06-21 19:26:00 Richard Kistruck MPS br/diag: fin1658a: confirms defect described in job001658.

Generated at 2008-07-09 03:00:57 by $Id: //info.ravenbrook.com/infosys/cgi/issue.cgi#430 $

Copyright © Ravenbrook Limited. This document is provided "as is", without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this document. You may not duplicate or reproduce this document in any form without the express permission of the copyright holder.

Ravenbrook / Projects / Memory Pool System / Issues