Title | Finalization messages are unnecessarily delayed. |
Status | closed |
Priority | essential |
Assigned user | David Jones |
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). RHSK 2008-12-19 Test zmess.c subsumes and replaces test fin1658a.c |
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...iag/code/exp-162647/0622a-tFGreport.txt |
Observed in | 1.107.0 |
Created by | David Jones |
Created on | 2007-06-04 12:09:40 |
Last modified by | Richard Kistruck |
Last modified on | 2008-12-19 14:50:52 |
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 2008-12-19 RHSK zmess.c subsumes and replaces test fin1658a.c |
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. |