Changes between Version 28 and Version 29 of RTSsummaryEvents

Show
Ignore:
Timestamp:
01/16/12 11:24:33 (3 years ago)
Author:
MikolajKonarski (IP: 95.160.111.162)
Comment:

propose memory events

Legend:

Unmodified
Added
Removed
Modified
  • RTSsummaryEvents

    v28 v29  
    55Here is a [https://github.com/Mikolaj/ThreadScope/raw/working/SummaryPanelMockup.png screenshot] 
    66of what we can already do using the current set of events. It so happens we can do as much for the whole runtime 
    7 as for the selected time intervals with the currently available events, but in general, intevals require more kinds of events and more samples. Similarly, when we visualise some of this as graphs and especially graphs of rates of change of some values (e.g., memory usage), more frequent sampling will be required. 
     7as for the selected time intervals with the currently available events, but in general, intervals require more kinds of events and more samples. Similarly, when we visualize some of this as graphs and especially graphs of rates of change of some values (e.g., memory usage), more frequent sampling will be required. 
    88 
    99The first line of +RTS -s follows. 
     
    3939}}} 
    4040 
    41 The "total memory in use" is stored in the mblocks_allocated global var. 
    42 Check how often it changes and emit accordingly. 
     41The peak "total memory in use" to date is stored in the peak_mblocks_allocated global var. It changes often, but we can't spam too much, so let's emit it only after each GC, and not the peak value to date, but the current value. 
    4342 
    4443{{{ 
     
    5251}}} 
    5352 
    54 so it's a difference between total memory allocated from the OS (peak_mblocks_allocated), 
    55 and total memory in use by the GC and other parts of the RTS (hw_alloc_blocks). 
    56 Presumably, all the events needed so far are of the latter kind (really used), 
    57 so the former (allocated from the OS) may need a new event. 
     53Note 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). 
    5854 
    5955{{{ 
     
    153149== The list of needed new events == 
    154150 
     151A 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 
     153=== Memory stats events === 
     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 
     156 
     157* MEM_COPIED(number_of_bytes) emitted after each GC, with the number of bytes copied during that GC 
     158 
     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 
     160 
     161* MEM_SLOP(number_of_bytes) emitted after each GC, with the current slop in bytes 
     162 
     163* MEM_TOTAL(number_of_bytes) emitted after each GC, with the total number of mblocks allocated from the OS 
     164 
     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 
     167=== GC stats events === 
     168 
    155169TODO 
     170 
     171=== Assorted events === 
     172 
     173TODO