Changes between Version 29 and Version 30 of RTSsummaryEvents

Show
Ignore:
Timestamp:
01/16/12 13:00:43 (3 years ago)
Author:
MikolajKonarski (IP: 95.160.111.162)
Comment:

complete the list of event changes

Legend:

Unmodified
Added
Removed
Modified
  • RTSsummaryEvents

    v29 v30  
    5151}}} 
    5252 
    53 Note that it used the peak and high-water values and we instead want 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). 
     53Note 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). 
    5454 
    5555{{{ 
     
    147147I'd guess the elapsed time should always be higher than the CPU time, shouldn't it? 
    148148 
    149 == The list of needed new events == 
     149== The list of needed new events or even parameters == 
    150150 
    151151A 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). 
    152152 
    153 === Memory stats events === 
     153=== New memory stats events === 
    154154 
    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 
    156156 
    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) 
    158158 
    159159* 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 
     
    165165* 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 
    166166 
    167 === GC stats events === 
     167=== New parameters for GC stats events === 
    168168 
    169 TODO 
     169Extra "generation" parameter is needed for one of GC_START or GC_END. 
     170If we have the extra parameter in both, we can do more with partial eventlogs 
     171that lack starts of ends of some GCs, and it's easier to calculate stats 
     172for selected time intervals. When the RequestSeqGC and RequestParGC events 
     173are emitted, it's not yet know if the GC will be major or minor, so no extra 
     174parameters should be added to them. 
    170175 
    171 === Assorted events === 
    172  
    173 TODO 
     176While we tinker with these events, we could try to ensure 
     177that RequestSeqGC and RequestParGC are emitted before their corresponding 
     178GC_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".  
     180Currently they can be emitted in arbitrary order and it complicates analysis,  
     181especially for selected intervals (and complicates and makes less strict 
     182the future validation of the events).