| Title | Configura would like "control over finalization promptness" |
| Status | closed |
| Priority | optional |
| Assigned user | Gareth Rees |
| 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 | DRJ 2007-03-19: 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. (RHSK 2007-06-13: 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. GDR 2013-03-08: Is this still a problem? The manual clearly documents [5] that finalization is not a suitable tool for prompt freeing of scarce resources, and explains what to do instead (provide the programmer with a way to declare the extent of the resource). If this is not longer a problem, I propose we close this job as "won't fix". GDR 2013-03-12: RB asked Göran [7] whether this is still a problem for him, and he replied [8] that it is "Very low prio because we have designed things differently." Accordingly I marked the job as closed by change 180012 (which documented the absence of timeliness guarantees in MPS finalization). |
| How found | customer |
| Evidence | [1] <https://info.ravenbrook.com/mail/2007/03/16/14-39-12/0/> e-mail from Göran, subject "GC priority to external resources".[2] < https://info.ravenbrook.com/mail/2007/03/04/17-13-19/0/> e-mail from Göran (to one of his staff, CCed to us), subject "RE: Autocad crash glPainter".[3] < https://info.ravenbrook.com/mail/2006/12/16/10-49-34/0/> e-mail from Göran, subject"RE: Configura prompt finalization of LWWs [Re: list of topics]"[4] < https://info.ravenbrook.com/mail/2006/12/11/12-21-29/0/> e-mail from Göran, subject "RE: Using AMCZ -- might complicate investigation"[5] < https://info.ravenbrook.com/mail/2007/03/16/18-32-40/0/> 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[6] < http://info.ravenbrook.com/project/mps...l/html/topic/finalization.html#cautions>[7] < https://info.ravenbrook.com/mail/2013/03/12/13-17-41/0/>[8] < https://info.ravenbrook.com/mail/2013/03/12/14-44-07/0/> |
| Created by | David Jones |
| Created on | 2007-03-19 11:59:28 |
| Last modified by | Gareth Rees |
| Last modified on | 2014-04-06 15:18:05 |
| 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. 2013-03-08 GDR Propose closing. 2013-03-12 GDR Reference RB's query and Göran's response. |
| Change | Effect | Date | User | Description |
|---|---|---|---|---|
| 180012 | closed | 2012-10-22 16:39:30 | Gareth Rees | Write finalization chapter of reference manual. |
| 162600 | open | 2007-06-19 10:39:38 | David Jones | MPS: clarified reference manual for the finalization bits. |