| Title: | MPS _gc_start messages may change while client reads them, or be silently skipped |
| Status: | open |
| Priority: | optional |
| Assigned user: | Richard Kistruck |
| Product: | mps |
| Organization: | Ravenbrook |
| Description: | MPS _gc_start messages may change while client reads them, or be silently skipped RHSK 2006-12-27 If the client's processing (via mps-message_get(), mps_message_gc_start_why(), and mps_message_discard()) of the _gc_start message is 'too late', then the collection this message was about may have already finished and another one begun. In this case, the MPS will overwrite the data in the first message (such as the "why" reason that the collection started), with data pertaining to the second collection, while the client is still reading the message. Furthermore, no message will be posted for the second collection start. This arises because the MPS unsafely reuses a single message structure for all _gc_start messages. There is no indication that overwriting has occurred or that _gc_start messages have been omitted. Overwrites and omissions could be avoided by the client processing _gc_start messages 'in time', in other words before a second collection has begun. However, this is not always possible: MPS collection scheduling may advance the first collection very 'fast' (relative to client speed) by setting a high trace->rate, in other words a very small nPolls, perhaps even as low as 1, thereby preventing the client from processing the _gc_start message. |
| Analysis: | RHSK 2006-12-27 See design/message for the lifecycle of a message. After the client calls Get(), the message is in state "received". It would be clearer to call this state "atclient". The MPS Message System provides no support for an Originator that needs to know when the message is still "atclient". This support should be added at the Message System level, perhaps with a new function MessageAtClient(). Examine Originator code for both _gc_start and _finalize messages, and consider using MessageAtClient(). Note that it is prudent to pre-allocate _gc_start messages, as there may not be memory available when a GC starts. DRJ 2007-06-19 MPS should not change message whilst it is at client (using MessageAtClient, see above). MPS should have some way of saying how many messages were "dropped". For example a field in each message could record how many messages were dropped prior to this one. |
| How found: | unknown |
| Evidence: | http://info.ravenbrook.com/infosys/cgi/perfbrowse.cgi?@describe+161203 |
| Observed in: | 1.107.0 |
| Introduced in: | 1.107.0 |
| Test procedure: | none |
| Created by: | Richard Kistruck |
| Created on: | 2006-12-27 16:35:51 |
| Last modified by: | David Jones |
| Last modified on: | 2007-06-19 11:21:17 |
| History: | 2006-12-27 RHSK Created. 2007-06-19 DRJ Notes on what would be desirable. |
Generated at 2008-10-12 10:16:40 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.