Changes between Version 28 and Version 29 of RTSsummaryEvents

Timestamp:

01/16/12 11:24:33 (16 months ago)

Author:

MikolajKonarski (IP: 95.160.111.162)

Comment:

propose memory events

RTSsummaryEvents

@@ -5 +5 @@
 Here is a [https://github.com/Mikolaj/ThreadScope/raw/working/SummaryPanelMockup.png screenshot]
 of what we can already do using the current set of events. It so happens we can do as much for the whole runtime
-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.
+as 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.
 
 The first line of +RTS -s follows.
@@ -39 +39 @@
 }}}
 
-The "total memory in use" is stored in the mblocks_allocated global var.
-Check how often it changes and emit accordingly.
+The 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.
 
 {{{
@@ -52 +51 @@
 }}}
 
-so it's a difference between total memory allocated from the OS (peak_mblocks_allocated),
-and total memory in use by the GC and other parts of the RTS (hw_alloc_blocks).
-Presumably, all the events needed so far are of the latter kind (really used),
-so the former (allocated from the OS) may need a new event.
+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).
 
 {{{
@@ -153 +149 @@
 == The list of needed new events ==
 
+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).
+
+=== Memory stats events ===
+
+* 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
+
+* MEM_COPIED(number_of_bytes) emitted after each GC, with the number of bytes copied during that GC
+
+* 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
+
+* MEM_SLOP(number_of_bytes) emitted after each GC, with the current slop in bytes
+
+* MEM_TOTAL(number_of_bytes) emitted after each GC, with the total number of mblocks allocated from the OS
+
+* 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
+
+=== GC stats events ===
+
 TODO
+
+=== Assorted events ===
+
+TODO