![(please configure the [header_logo] section in trac.ini)](/ThreadScope/chrome/site/your_project_logo.png){kind=logo}
Changes between Version 29 and Version 30 of RTSsummaryEvents
- Timestamp:
- 01/16/12 13:00:43 (17 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
RTSsummaryEvents
v29 v30 51 51 }}} 52 52 53 Note that it use d the peak and high-water values and we instead wantcurrent values. It's calculated as the difference of mblock and block allocations, so we need an extra events for allocated block (mblocks are already recorded in "total memory in use" above).53 Note that it uses the peak and high-water values and we instead want the current values. It's calculated as the difference of mblock and block allocations, so we need an extra events for allocated block (mblocks are already recorded in "total memory in use" above). 54 54 55 55 {{{ … … 147 147 I'd guess the elapsed time should always be higher than the CPU time, shouldn't it? 148 148 149 == The list of needed new events ==149 == The list of needed new events or even parameters == 150 150 151 151 A rough proposal, in particular the names are ad hoc and the units are provisional (e.g., words or blocks would be more natural for memory events, but TS does not know their sizes). 152 152 153 === Memory stats events ===153 === New memory stats events === 154 154 155 * MEM_ALLOCATED(number_of_bytes) emitted after (or just before?) each GC, with the number of bytes allocated in the heap since the previous GC 155 * MEM_ALLOCATED(number_of_bytes) emitted after (or just before?) each GC, with the number of bytes allocated in the heap since the previous GC, or a running total 156 156 157 * MEM_COPIED(number_of_bytes) emitted after each GC, with the number of bytes copied during that GC 157 * MEM_COPIED(number_of_bytes) emitted after each GC, with the number of bytes copied during that GC (this one could also be counted as a GC_ event, not MEM_ event, because it's only about the particular memory operations of a copying GC) 158 158 159 159 * MEM_RESIDENCY(number_of_bytes) emitted after each major GC (too rarely, but after minor GC the figure is too inaccurate, probably), with the total number of bytes of memory actually used (as opposed to allocated from the OS) by the program … … 165 165 * MEM_TOTAL_BLOCK(number_of_bytes) emitted after each GC, with the total memory of blocks allocated inside the mblocks allocated from the OS, used to calculated the memory lost due to fragmentation of mblocks 166 166 167 === GC stats events ===167 === New parameters for GC stats events === 168 168 169 TODO 169 Extra "generation" parameter is needed for one of GC_START or GC_END. 170 If we have the extra parameter in both, we can do more with partial eventlogs 171 that lack starts of ends of some GCs, and it's easier to calculate stats 172 for selected time intervals. When the RequestSeqGC and RequestParGC events 173 are emitted, it's not yet know if the GC will be major or minor, so no extra 174 parameters should be added to them. 170 175 171 === Assorted events === 172 173 TODO 176 While we tinker with these events, we could try to ensure 177 that RequestSeqGC and RequestParGC are emitted before their corresponding 178 GC_START events, by using the following tip from JaffaCake: 179 "actually you could try moving the interruptAllCapabilities() call in Schedule.c:1500 down below the traceEvent calls". 180 Currently they can be emitted in arbitrary order and it complicates analysis, 181 especially for selected intervals (and complicates and makes less strict 182 the future validation of the events).
