Ravenbrook / Projects / Memory Pool System / Issues

Memory Pool System


MPS issue job001639

Title: Configura would like "control over finalization promptness"
Status: open
Priority: essential
Assigned user: David Jones
Product: mps
Organization: Ravenbrook
Description: Configura would like "control over finalization promptness".

In particular Göran suggests: "prioritized collection of objects
wrapping external resources". In other words he wants to denote
a particular set of objects as wrapping external resources (well,
he probably doesn't want to, but I expect he wouldn't mind having
to do so); and, wants those objects to be collected on a particular
schedule. See [1].

e-mail [2] suggests that the "external resources" are 3D primitives of some sort. Presumably the 3D primitives need to be explicitly released from a 3rd party libraries control.

e-mail [3] gives some more data on the numbers of objects that
Configura expect to manage this way: 10000 objects that "stand
for" 25e6 triangles.

e-mail [5] include some actual object counts dumped from a running CM.
28 objects for a total of about 1 KB. But they stand for a much larger
bunch of 3D mesh objects. So there's a related issue that MPS could
usefully know that this tiny object will result in large amounts of
memory being freed when it dies.
Analysis: 2007-03-19 DRJ:

Göran's approach seems reasonable, at least to start with. We need to clearly document the dangers of using finalisation for anything prompt; and also the danger that this approach may lead to worse performance overall.

(2007-06-13 RHSK: I asked DRJ to expand on "the dangers of using finalisation for anything prompt", and my paraphrase of his explanation is: finalisation cannot guarantee promptness, so don't rely on it to avoid fatal exhaustion of a hard-limited resource (see [Boehm] for why all finalisation is limited like this). But it's ok expect to use finalisation to help reduce consumption of soft-limited non-fatal resources.)

We would do well to find out more about what Göran and Configura intend doing exactly.

General awareness of what collections are happening would help as well, then Göran could see what object were being finalised when and why (or why not).

E-mail [4] gives Configura startup code, which presumably
includes details of how chains are allocated to pools. This
critically affects how generations co-operate to be collected
together.

The following jobs are related:

job001156, "MPS cannot queue a message when a weak thing goes away", may also be of use in that it implements a sort of finalisation.

job001150, "MPS doesn't provide enough feedback", feedback would give insight into promptness of finalisation.
How found: customer
Evidence: [1] //info.ravenbrook.com/mail/2007/03/16/14-39-12/0.txt e-mail from Göran, subject "GC priority to external resources".
[2] //info.ravenbrook.com/mail/2007/03/04/17-13-19/0.txt e-mail from Göran (to one of his staff, CCed to us), subject "RE: Autocad crash glPainter".
[3] //info.ravenbrook.com/mail/2006/12/16/10-49-34/0.txt e-mail
from Göran, subject"RE: Configura prompt finalization of LWWs
[Re: list of topics]"
[4] //info.ravenbrook.com/mail/2006/12/11/12-21-29/0.txt e-mail from
Göran, subject "RE: Using AMCZ -- might complicate investigation"
[5] //info.ravenbrook.com/mail/2007/03/16/18-32-40/0.txt e-mail
from Göran, subject "RE: GC priority to external resources
[Boehm] http://www.hpl.hp.com/techreports/2002/HPL-2002-335.html
paper "Destructors, Finalizers, and Synchronization", by Hans-J. Boehm
Introduced in: 0.0.0
Test procedure: none
Created by: David Jones
Created on: 2007-03-19 11:59:28
Last modified by: David Jones
Last modified on: 2007-06-19 10:41:00
History: 2007-03-19 DRJ Created.
2007-03-21 DRJ More links to e-mails.
2007-06-13 RHSK Fix link to job001156.
2007-06-13 RHSK Expand on dangers of relying on finalisation.

Fixes

Change Effect Date User Description
162600 open 2007-06-19 10:39:38 David Jones MPS: clarified reference manual for the finalization bits.

Generated at 2008-11-21 22:09:09 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