Changes between Version 16 and Version 17 of RTSsummaryEvents

Show
Ignore:
Timestamp:
12/23/11 12:42:59 (2 years ago)
Author:
MikolajKonarski (IP: 95.160.111.162)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • RTSsummaryEvents

    v16 v17  
    88Here is a [https://github.com/Mikolaj/ThreadScope/raw/working/SummaryPanelMockup.png screenshot] 
    99of what we can already do using the current set of events. It happens we can do as much for the whole runtime  
    10 as for time intervals in this case. 
     10as for the time intervals in this case. 
    1111 
    1212{{{ 
     
    1414}}} 
    1515 
    16 We need an event for each memory allocation. 
     16We'd need an event for each memory allocation to calculate the total allocated heap. 
    1717 
    1818{{{ 
     
    2020}}} 
    2121 
    22 An event with a summary of all copying done, after the end of each GC, probably. 
     22An event with a summary of all copying done, probably after the end of each GC. 
    2323 
    2424{{{ 
     
    2626}}} 
    2727 
    28 Either a separate event for that, perhaps emitted only after major GC, when we know how much memory 
    29 is really used by the program (the docs explain the "n samples" saying "only checked during major garbage collections").  
    30 Or try to calculate it (how often to sample?) from all events. in particular memory deallocation events or GC memory freeing events. 
     28Either a separate event for that, perhaps emitted only after major GC when we know how much memory 
     29is really used by the program. The docs explain the "n samples" above saying "only checked during major garbage collections".  
     30Or we can try to calculate it (how often to sample?) from all events. in particular memory deallocation events and GC memory freeing events. 
    3131 
    3232{{{ 
     
    4646}}} 
    4747                   
    48 Ask JaffaCake what the following formula means: 
     48No idea. Ask JaffaCake what the following formula means: 
    4949 
    5050{{{ 
     
    7474by any thread in a single par GC. Events needed: the events added above suffice, 
    7575but quite a bit of extra state will have to be maintained when reading 
    76 the events. Perhaps +RTS -s could be modified to make this figure simpler? 
     76the events. Ask JaffaCake if +RTS -s could be modified to make this figure simpler. 
    7777 
    7878{{{ 
     
    8585 
    8686Ask JaffaCake how the "tasks" relate to the "threads" for which we generate  
    87 events. Perhaps to the existing GC events we can add the info about which task 
    88 does the job. BTW, is the time between event GCIdle and GCWork counted 
     87events. For now, to the existing GC events we can add the info about which task 
     88does the job, but may miss something this way. BTW, is the time between event GCIdle and GCWork counted 
    8989as GC time of the task? Generally, is GCIdle useful for us here in any way? 
     90Similarly, can be calculate the MUT (elapsed) times just but taking the total 
     91time a thread (or cap?) is run and subtracting the GC time and any pauses (and are all 
     92pauses visible through events we have already?). 
    9093 
    9194{{{