| Title | MPS clients get no synchronous alert of collection begin/end |
| Status | closed |
| Priority | essential |
| Assigned user | Richard Kistruck |
| Organization | Ravenbrook |
| Description | MPS clients get no synchronous alert of collection begin/end Summary: mps_alert_collection_set(&alertfn) -- new function in mps.h (*alertfn)(MPS_ALERT_COLLECTION_BEGIN/END, whycode); Related jobs: job001969: "MPS gc-start and -end messages give no idea of timing" RHSK 2008-11-12 There's not much a client can do with a synchronous alert, because it may happen at any time (particularly: at interrupt time while other client code and MPS code is in the middle of arbitrary operations), beyond note the time it happens. However, this is exactly what is wanted to help performance tests of client program operations: it permits compensation for the effect of MPS collections. (At worst: ignoring that run and trying again, hoping not to trigger any collection at all). |
| Analysis | RHSK 2008-11-12 Can we synchronously deliver the gc-start and -end messages? No: it would not be safe for clients to read the messages (via message accessor functions) while the MPS is re-entrant. How about timestamps on messages? Yes: see job001969. But a synchronous alert to client callback code that can only do very little would also be helpful. __Implementation__ Simple: mps_alert_collection_set stores a function pointer in ArenaStruct. The tracer, immediately after posting a gc-start or -end message, calls the callback (if non-null) as well. The callback receives two ints: alertcode (either of: MPS_ALERT_COLLECTION_BEGIN MPS_ALERT_COLLECTION_END ) (see mps.h), and whycode (any of: TraceStartWhyCHAIN_GEN0CAP, /* start minor */ TraceStartWhyDYNAMICCRITERION, /* start full */ TraceStartWhyOPPORTUNISM, /* start full */ TraceStartWhyCLIENTFULL_INCREMENTAL, /* start full */ TraceStartWhyCLIENTFULL_BLOCK, /* do full */ TraceStartWhyWALK ). Note: callback is also called for heap walk begin/end. RHSK 2009-02-17 Use "begin/end" throughout, instead of "start/stop". mps.h now has MPS_ALERT_COLLECTION_BEGIN, MPS_ALERT_COLLECTION_END. |
| How found | unknown |
| Evidence | none |
| Observed in | 1.108.2 |
| Created by | Richard Kistruck |
| Created on | 2008-11-12 15:20:56 |
| Last modified by | Richard Kistruck |
| Last modified on | 2010-03-03 15:08:18 |
| History | 2008-11-12 RHSK Created. 2009-02-17 RHSK Use "begin/end" throughout, instead of "start/stop". |
| Change | Effect | Date | User | Description |
|---|---|---|---|---|
| 169914 | closed | 2010-03-03 15:08:08 | Richard Kistruck | MPS master: add "mps_alert_collection_set" to w3gen.def. (So that if this .def file is used to re-export MPS functions from a client executable, mps_alert_collection_set() will be exported, along with all the other MPS interface functions). |
| 167386 | closed | 2009-02-16 17:11:05 | Richard Kistruck | MPS br/timing: rename MPS_ALERT_COLLECTION_*. The correct term for when a new MPS operation begins is "Begin", and when it ends is "End". (Whereas several starts/stops may happen during a single MPS operation). |
| 166703 | closed | 2008-11-12 15:07:04 | Richard Kistruck | MPS br/timing: mps_alert_collection_set() -- client sets a callback function; MPS calls it synchronously on collection start/stop (immediately after posting start/stop message). The callback receives two ints: alertcode (start|stop; see mps.h), and whycode (trace->why). Note: callback is also called for heap walk start/stop. amcss.c: show start/stop alerts. |